Le 27/11/2012 15:37, Ole a écrit :
Hum I think I not explain very well this morning (I need to go too fast!), I not want to said the full area but the full rectangle to be redraw (for example a window move above to another window of 10 pixels on all the height of the widows beneath, then the AES could send a WM_REDRAW of 10 pixels width with the height on the window, now suppose above the redraw there is another window above and the area to be redraw is partially coverd by this window, in the case of MyAES it send only the area to be updated and we could imagine to have the same message as describe. I think it work (I hope all program use wind_get(WF_FIRSTXYWH or WF_NEXTXYWH) doing rc_intersect with the rectangle sent in WM_REDRAW) and it is better because you have less messages to manage and less call to wind_get()), and the top for an application to reduce even more number of wind_get(WF_FIRSTXYWH or WF_NEXTXYWH) you can replace WF_FIRSTXYWH by WF_FIRSTAREAXYWH (13) supported by MyAES and XaAES you call wind_get(WF_FIRSTAREAXYWH,....) with area ask by MW_REDRAW. in the case of MyAES sometime I do small opimisation to reduce the number of redraw messages.Am Dienstag, den 27.11.2012, 07:12 +0100 schrieb OL <o.l@lutece.net>:In MyAES case, I send message for each rectangles to redraw of a windows but it's possible this is not need I think send the full window is enough and finally more efficient, I will look at this.Well, it only makes sense to merge areas which intersect, sending full windowisn't a good optimization.... Of course it depends on the application... but with netsurf I keep a list of redraw areas, because it's faster to redraw several small area instead of one large... but on the other handit's not fine to send WM_REDRAW for each small area... ( at least not when there is no optimization after the WM_REDRAW has been sent...) - that's whyI manage an internal list of areas which require redraw.If the AES would optimize the scheduled redraw areas, I would maybe changethat behavior... Greets, Ole
Olivier