[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-layout
Subject:    Re: Window Resize Algorithm
From:       Matt Jones <jone1941 () yahoo ! com>
Date:       2003-01-05 19:47:43
[Download RAW message or body]

L. David Baron wrote:
> On Sunday 2003-01-05 11:18 -0500, Matt Jones wrote:
> 
>>My proposed fix would actually surpass the performance of MSIE, however, 
>>it requires a leap of fail where the developer would have to assume 
>>(cringe) that the screen size could never be bigger than XbyY and thusly 
>>we could assume Z amount of content above/below the current viewable 
>>area would be needed.  Given that assumption we would only resize that 
>>much content while the windows is being resized and the would redraw all 
>>content when the resize is complete.  While I am a developer, I am not 
>>experienced with 2D layout, and so, if my logic is flawed, please let me 
>>know.
> 
> 
> Given positioning, floating, etc., I think it could be difficult to
> figure out what content will be in the top part of the screen without
> actually laying it out (although there probably are some optimizations
> that could be done).
> 
> However, there are other problems.  How would you figure out the correct
> length to draw the scrollbar?  Are there Windows APIs for determining
> what resizing state a window is in, and how would those be connected to
> the layout engine?
> 
> -David
> 

I don't know if you have IE installed, but if you try it out, you can 
see that it attempts to make the size of the scrollbar represent the 
length of all content upto the current position in the document.  As far 
as a recommendation, I would suggest (as above) that there is some value 
for which noones screen can get any larger than, that will still provide 
a faster redraw than the current.  So, we can always assume the same 
amount of data (or less) during a resize.  In response to the Windows 
APIs question.  I don't think so, but the timing could be managed 
internally, if a request to resize does not come in for some fraction of 
a second, it can be decided that redrawing has stopped.

I don't have a personal conviction to see this behavior, however I would 
like to see an improvement in performance.  You mentioned other 
optimizations that could be done, can you elaborate?

-Matt


[prev in list] [next in list] [prev in thread] [next in thread]