Scroll list bugs
Fred Graute (114) 645 posts |
As mentioned before the scroll list memory handling is poor. It seems to only claim enough space for a new item to add rather than claiming a large block and allocating from that. This leads to lots of new blocks claimed from the RMA as the old one wasn’t big enough, because of this adding many items is slow. The old blocks don’t seem to get released until the scroll list is removed on application exit, so more and more space is taken from the RMA. Changing the scroll list font doesn’t seem to recalculate the new window extent so there’s either a blank area at the bottom of the scroll list or the last items can no longer be reached. Looking at the code, there’s a function _set_extent() but _set_font() isn’t calling it, though it probably should. The assembler function scrolllist_update() doesn’t release the workspace claimed from the stack when the call to XWimp_UpdateWindow fails so returns to some random address. Adding a The memory and font issues can both be seen in ExifEdit |
Sprow (202) 1159 posts |
Unless I’m looking at something different to you, the scrolllist_update function is switched out and just returns doing nothing. Is this a theoretical bug? Otherwise how did you trigger it? |
Fred Graute (114) 645 posts |
Sorry, must have missed that – seen lots of source files yesterday. It does mean that the problem with _set_font is even bigger, not only does it fail to set a new extent, it doesn’t even redraw the scroll list when the font changes. Same when changing the colours, no redraw. Of the 4 calls to scrolllist_update two have been replaced by calls to Window_ForceRedraw but not those that are associated with _set_colours and _set_font. I can’t see any reason why they couldn’t be replaced as well, so this might be an easy fix. Looking at ExifEdit, I see that I added code to reselect the current tab just to force a redraw so you don’t get partially updated bits when scrolling or dragging over. Of course that doesn’t fix the window extent problem. |