The render queue blocks on unready video frames and triggers the
`_flushing` mechanism in rfb.js, which stops all VNC message
processing. This starves the VideoDecoder of input, preventing it
from producing output — creating a deadlock where the queue waits
for decoder output that can never arrive.
Video frames now skip the queue blocking and draw asynchronously
via the decoder's output callback. The flip operation waits for all
pending frames to resolve before executing, preserving visual
correctness without blocking the decoder input pipeline.
`self` refers to `window` in browser context, causing SPS parameters
to be set on the global object instead of the H264Context instance.
This prevents the decoder from ever being properly configured.
Some encodings don't know how much data they need, rather they must
probe the data stream until they find an end marker. Expose how much
data is buffered in order to make this search efficient.
Helps the browser to free up the memory right away, rather than waiting
until some later cleanup process. At least Firefox can start consuming
gigabytes of memory without this.
We want to flush pending mouse moves before we initiate viewport
dragging.
Before this commit, there were scenarios where the _mouseButtonMask
would track a released button as being down.
Instead of keeping track of button states ourselves by looking at
MouseEvent.button, we can use the MouseEvent.buttons which already
contains the state of all buttons.
Since the expected client size wasn't updated when the browser window
resized, noVNC didn't resize the canvas properly when going back to
the exact same dimensions.
Fixes issue #1903
Try to be more consistent in how we capitalize things. Both the "Title
Case" and "Sentence case" styles are popular, so either would work.
Google and Mozilla both prefer "Sentence case", so let's follow them.
The Firefox H.264 decoder on Windows might simply just refuse to deliver
any finished frames. It also doesn't deliver any errors.
Detect this early by expecting a frame after flush() has completed.
Firefox is buggy and reports support for H.264 but then throws errors
once we actually try to decode things. Detect this early by doing a
quick test decode of a single frame.
It sets KeyboardEvent.key to "Unidentified" for all non-character keys,
which means we must ignore it and use the legacy handling to figure out
the key pressed.
Previously, num-lock and caps-lock syncing was performed on a best effort basis by qemu.
Now, the syncing is performed by no-vnc instead. This allows the led state syncing to work
in cases where it previously couldn't, since no-vnc has with this extension knowledge of both
the remote and local capslock and numlock status, which QEMU doesn't have.
The code comment of this code was entirely incorrect, but the commit
message for 5671072 when it was added was correct. I.e. there is a
result, but not a reason.
Adjust the unit tests to make sure this doesn't regress again.
There is just one argument to inflateInit(). It is inflateInit2() that
takes two arguments.
Since this argument was never used, let's just remove it and keep the
existing behaviour.
This was an accidental copy error from inflator.js. The second argument
to deflateInit() is the compression level, not the window bits.
We have not strong opinions on an appropriate level, so stick to the
default.
We don't know how long the caller will hang on to this data, so we need
to be safe by default and assume it will kept indefinitely. That means
we can't return a reference to the internal buffer, as that will get
overwritten with future messages.
We want to avoid unnecessary copying in performance critical code,
though. So allow code to explicitly ask for a shared buffer, assuming
they know the data needs to be consumed immediately.
keradoxchen