I am going over the permessage-deflate rfc and I don't understand the part about 'sharing LZ77 Sliding window' (section 7.2.3.2.)
It says that If the "agreed parameters" did not contain the "client_no_context_takeover" extension parameter, the client can compress the payload of the next message into less bytes by referencing the history in the LZ77 sliding window.
How will the server know if the client used the same sliding window or used a new one?
How will the server decompress the message?
How can I use Zlib(or any other lib) to compress/decompress a message like this?
If client_no_context_takeover is agreed to, then always assume that the next message can use the previous sliding window contents. If it doesn't then the previous window will not be referenced and no harm is done. You must continue to assume that any compressed message can refer to the sliding window and update the sliding window, since the third message could refer to the first and second messages in the sliding window, even if the second message didn't refer to the first.
To decompress, maintain a zlib inflate instance and continue to feed it compressed data. The inflate instance will maintain the sliding window for you. Append 00 00 ff ff to each compressed message and feed that to inflate(). Each subsequent message will use the sliding window built of previous messages, if referred to in the compressed data.
Related
A user has a business card with two sides. It has the front side with primary information and the backside with secondary details. She wants that when she sends her business card to her contacts, they should see the front side of it only. And after clicking on it, it should flip to another side. The image should just be a gif or any other image format independent of any program.
All I can think of creating a gif which after an interval changes to the other side which does not fulfill her requirement of changing only when clicked.
I thought of ImageMap with hotspots but that too will require linking the other side (page) on the web which defies the independence of the image.
Any help in this regard is highly appreciated.
The GIF89a standard (the one we use today) includes the so-called User Input flag that was designed exactly for this.
That flag, being set on a certain frame, should tell a GIF decoder not to show the next frame until either the timeout expires or the user interacts with the current one.
Zero timeout coupled with nonzero User Input means that the decoder should wait for an interaction indefinitely.
Quote from the standard:
v) User Input Flag - Indicates whether or not user input is
expected before continuing. If the flag is set, processing will
continue when user input is entered. The nature of the User input
is determined by the application (Carriage Return, Mouse Button
Click, etc.).
Values : 0 - User input is not expected.
1 - User input is expected.
When a Delay Time is used and the User Input Flag is set,
processing will continue when user input is received or when the
delay time expires, whichever occurs first.
Unfortunately, no GIF decoders I know of even bother to handle this flag properly — so I guess your best bet is to give both frames reasonable timeouts, 10±5 seconds or so.
Situation: I am working on an overlay application that needs to intercept the input headed to another process and block that input if necessary.
Previous Attempts: So far I have created a low level mouse hook that blocks mouse input to some target processes; however, the process I am interested in is not affected. I believe this is because the process uses Raw Input instead of usual windows messages.
Question: How can I swallow these Raw Input mouse messages?
I'm trying to prevent my rendering from stopping when my window is out of focus or resizing. In addition to the resizing, if I resize my window smaller, then bigger again anything that wasn't visible when it was smaller is now black. Is there any way to fix this?
There are really two distinct things going on here. The moving/resizing problem is caused by the windows DefWindowProc function which applications use to handle messages that aren't explicitly handled by the application itself. In the case of moving or resizing, it blocks, creating a new message queue to handle most messages, but there are a few that it will still dispatch to the application's main event queue, like WM_TIMER. You can find lots more information in this answer.
The second issue is that your program only "owns" the pixels inside your window, and only those that are not covered up by other windows. When you make the window smaller, the pixels at the edge need to be overwritten to show the window border or whatever's behind the window. When the window is made bigger, some drivers automatically set the newly acquired pixels to black, while others leave them at whatever they were before (usually part of the window border). The OS doesn't remember if those pixels had some specific color the last time the window was that size, because most of the time the program doesn't care. Instead, windows sends a WM_PAINT message to indicate that the application should redraw the window. Your program should either directly handle this, or use a library like GLFW that abstracts it. In addition, you need to handle resize events by calling glViewport with the new size of the window.
In reference to Windows GDI, what is the difference between an invalid and valid region? I understand that a call to InvalidateRect() sends a WM_PAINT message to the queue, but what exactly is an "invalid" region?
I understand that a call to InvalidateRect() sends a WM_PAINT message to the queue.
Well, not exactly. When you call InvalidateRect, you mark that rectangular region as being invalid and needing to be repainted. But no messages are sent. In fact, no message is even posted to the queue.
When you call GetMessage, or one of its equivalents, if the queue is empty, and there are windows in the thread that have dirty regions, then the system synthesises a WM_PAINT message. This synthesised WM_PAINT message is returned from GetMessage. The window's handler for WM_PAINT should then paint the window and thus make it valid again.
So, an invalid region is one that is pending painting. You have told the system that you want that region to be re-painted, and the system will arrange for that to happen once the higher priority queued messages have been processed.
The windowing system generally tries to avoid redrawing anything unless necessary, e.g. because something has changed, or another window has moved across it. When this happens, it marks the region as invalid to say that it needs to be redrawn. Alternatively, a region/window can be manually invalidated to force a redraw.
When the application responds to the WM_PAINT message, it will try to be as efficient as possible by only redrawing in the invalidated area. When it's finished, it marks it as valid to indicate that it's now up-to-date.
This selective redraw approach isn't as important today as it used to be. In the past, the drawing operations were much slower, so optimisation was absolutely essential.
I'm using XComposite extension to get contents of the windows running under a sort of window manager that I develop. I found that in many cases if I try to get contents of the window using pixmap created with XCompositeNameWindowPixmap shortly after it was mapped and redirected I get garbage image from the pixmap. Same call a little bit later gives perfectly valid image of the window.
My assumption is that it takes some time to initially populate the pixmap. Unfortunately, I'm not able to quantify how much more time I have to wait before I can get correct image.
Is there any way to determine if composited pixmap is ready to be used? Or is there anything else that might be causing this weird effect?
What you're experiencing is, that after redirecting a window the program has to redraw the window's contents, to those are not initially available right after redirection.
This is where the Damage extension enters the stage, which allows clients to inform other clients, that their window's contents have been updated.