L. David Baron wrote:
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.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 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
