FWD » Core Development » User Interface

If we press the maximize/restore caption button several times, then the window canvas displays two images one above the other. The top most image is the restored window image and the normal window image is below it.
For this case I found that the widget regions aren't correct because the regions for the caption buttons are shifted.

The WebGuiDriver: public synchronized void registerMouseWidgets() was changed to use InstrumentedMap<K,V> and the code became more complicated.

Please post a screenshot which shows the issue.

The problem with the drawing cache system is that resize messages are reached GuiWebDriver correctly, but due to the cache the resize messages are not sent to the JS web client. Since we don't cache the current canvas size with the cached drawing, we can watch this effect. We must save on the client side the current canvas size with the cached image and restore the image and the canvas size.

Sergey Ivanovskiy wrote:

The problem with cache system is that resize messages are reached GuiWebDriver correctly, but we don't cache the current canvas size with the cached drawing. Because of this we can watch this effect. We must save on the client side the current canvas size with the cached image and restore the image and the canvas size.

Please try this: change GuiWebSocket.md5Hash to include the window's size. This should be enough to distinguish between draw caches with different window sizes.

Checked that if we send the batch of resize drawing operations in case of there is a resize drawing operation, then the resize effect is gone. I think the problem is not the two drawing batch operations can't be separated by md5 hash sum but that the canvas can change its size and we don't track its size if the cached drawing is used. It is obvious that we can draw the small cached image on the large canvas but the canvas of the cached image can be less than the current canvas size. Thus we can watch different resize effects.

Code Review Task Branch 1811u Revision 11024

I'm fine with the changes.

Constantin: do you have any concerns?

Sergey Ivanovskiy wrote:

Please review the committed revision 11024. Utilizes the root cause that we mustn't cache the resize operations.

The idea is interesting, but what I don't understand is why are you sending the resize operations twice... for example, in GuiWebSocket.resizeWindow() you are still calling allocateAndSend(PaintPrimitives.RESIZE_WINDOW, width, height); - which will be batched with other drawing operations.

Is your idea that the resize operations are sent on their own, and the result is not cached?

Constantin Asofiei wrote:

Sergey Ivanovskiy wrote:

Please review the committed revision 11024. Utilizes the root cause that we mustn't cache the resize operations.

The idea is interesting, but what I don't understand is why are you sending the resize operations twice... for example, in GuiWebSocket.resizeWindow() you are still calling allocateAndSend(PaintPrimitives.RESIZE_WINDOW, width, height); - which will be batched with other drawing operations.

Is your idea that the resize operations are sent on their own, and the result is not cached?

Yes, it was sent twice because the order of drawing operations is important. Let drawings be directed by GUI classes. Thus we can't remove the resize operations from this sequence. The second resize is only to place and to resize a canvas. Do you think that we can extract the resize operations to send the batch message without resize, next resize and then without resize in general no more than three batch messages. But it needs more complicated processing.

What about my idea in note 9? Why wouldn't including into the md5 hash the window's size (as reported, in pixels, by i.e. WindowGuiImpl APIs) work? My understanding is that the problem is only in the global/full-window cache, not in the per-widget cache, correct?

Constantin Asofiei wrote:

Why wouldn't including into the md5 hash the window's size (as reported, in pixels, by i.e. WindowGuiImpl APIs) work?

I mean only in the md5 hash for the entire drawing op batch, not for the per-widget drawing.

Constantin, I don't try it, because the resize operations are performed on canvas object, but all cached drawings are performed on the context, they don't change the canvas size.

Sergey Ivanovskiy wrote:

Constantin, I don't try it, because the resize operations are performed on canvas object, but all cached drawings are performed on the context, they don't change the canvas size.

OK, so what you are saying is the canvas is not resized because the JS side "sees" the image already in the cache and draws it (thus the resize operations are never executed), right? Well, lets try it differently: if a drawing batch contains drawing operations, then just set the global md5 cache to zero (and don't cache the result).

Constantin Asofiei wrote:

Sergey Ivanovskiy wrote:

Constantin, I don't try it, because the resize operations are performed on canvas object, but all cached drawings are performed on the context, they don't change the canvas size.

OK, so what you are saying is the canvas is not resized because the JS side "sees" the image already in the cache and draws it (thus the resize operations are never executed), right? Well, lets try it differently: if a drawing batch contains drawing operations, then just set the global md5 cache to zero (and don't cache the result).

Ok, understand. Do you mean if the resize operation is inside the batch message, then don't cache it. I think it is the best solution.

Sergey Ivanovskiy wrote:

Do you mean if the resize operation is inside the batch message, then don't cache it. I think it is the best solution.

Yes, correctly - sendPendingDrawingOps should not set the global drawing cache.

I would like to cleanup this fix, because found that the magic byte array can be static and resizeOps can have type int.

Sergey Ivanovskiy wrote:

Committed rev 11026. Added the summary diff of the effective changes from 11024 to 11026.

The changes are OK.

Yes, the task is done.