Hi

I have (had) a window with 50 child-windows (each a data label). Double-buffering would not work as the paint time was just taking too long. Performance was very poor and my processor was being fully loaded.

Each child-window has its own timer to perform its own data check and refresh (if required). What I have tracked down (and now read in the manual) is that each WM_Invalidate() of a child window causes the parent window to undergo a full refresh. I do not understand why as the child-window is neither transparent nor has it moved location or changed size: there is no need for parent paint(). The problem is made worse as the parent then wants to repaint the background (800x480 c-coded image) and then paint all child-windows: performance drops off a cliff.

To resolve this I tried WM_CF_MEMDEV, tried CF_LATETILING and eventually just modified my code to switch off self-refresh of child windows and implement a timed parent window refresh. This works fine but should not be required and it limits my redraw speed to that of a full screen (about 3-4Hz at 800x480 resolution on 32F429I at 168MHz).

I also increased the background paint speed by loading the background converted bitmap to a MEMDEV and _draw that (I had hoped to store this background image in hardware vram buffer VRAMADDR0 to eliminate repeated repaint but that was not working: discussed in another thread).

I will eventually go back and look at this again (I would prefer self-refreshing window objects) but if you have comment it would be appreciated.

Thanks
Mark

Hi

I\m bumping this with some more information. I have spent a day or two trying to work out what is going on/come up with a work around. It turns out it is not the self-invalidating nature of the hWins that it the root of the problem. It is just, it seems, something at the heart of emWin's WM/rendering. I find that hard to say as I do know how thorough you are. But it feels like it.

See attached image: a keyboard. The background is an hwin onto which I have added (WM_CreateWindowAsChild) some 49 other hWin. I have set WM_CF_MEMDEV at boot of the GUI. The background hwin does NOT have WM_CF_HASTRANS set.

Performance drops off a cliff if the 49 child windows are set to WM_CF_HASTRANS. No windows overlap, none move, none are resized. Rendering is fine if the windows are opaque.

Whilst I do not need these buttons to be transparent I do in other windows. I am merely using this draft keyboard as an example of the issue.

What it "feels" like is that the rendering in emWin grabs the current background window image before each render of a child button. It does this due to the need to support transparency which I understand. However, the performance collapse indicates that, maybe, it is doing this with every child window. It does not need to: it need only do this if the child to be painted intersects with those windows already painted. In my example (the image attached) this would result in only a single grab of the background at the start as no window intersects another.

I cannot prove this as this is all in your code. But the performance makes transparency and moderate numbers of windows on a large surface/background/parent incompatible (I have just as many issues with a 4-button keyboard).

I just say that it feels like this is what is happening and I'd like some comment to say "no" or advice on something I can try. If this is what is happening then I know not to fight it.

Screen and driver info is in prior message.

Thanks
Mark