Opened 19 years ago
Last modified 17 years ago
#160 closed bug
[Tracker] icons disappear when resizing column width — at Version 7
| Reported by: | diver | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Servers/app_server | Version: | |
| Keywords: | Cc: | g.zachrisson@… | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
If you open a folder (for example /boot/beos/apps) and try to resize columnlistview several times you'll notice that:
- Resizing is slow
- icons will disappear
To show icons again you have to redraw current view with another window.
Change History (8)
comment:1 by , 19 years ago
| Summary: | Dissapearing icons → Disappearing icons |
|---|
by , 19 years ago
| Attachment: | resize_bug.PNG added |
|---|
comment:2 by , 19 years ago
| Cc: | added |
|---|
comment:4 by , 19 years ago
| bug_group: | → developers |
|---|
comment:5 by , 19 years ago
| Summary: | Disappearing icons → [Tracker] icons disappear when resizing column width |
|---|
comment:6 by , 17 years ago
| Platform: | → All |
|---|
This seems the best bug to deal with column resizing speed, even though it's not mentioned in the title.
Would it make sense to do some filtering of MouseMoved messages on the input_server side. For example, if the target message queue contains nothing but MouseMoved messages, would it be safe to remove the existing unprocessed ones before adding the new one?
I'm 90% sure there's something in the BeOS mozilla code (which has it's own weird event routing stuff) to do the same thing. If such a scheme existed on R5 (I think stippi mentioned column resizing doesn't involve as many move messages, though I could be wrong) then I can see that explaining the difference in behaviour.
I suppose I could write a test app that does something time consuming in response to the message and see what R5 does. Would that be useful?
comment:7 by , 17 years ago
| Description: | modified (diff) |
|---|
There is even a B_NO_POINTER_HISTORY flag for SetMouseEventMask() for this. However, we should not remove cursor events without need; some apps like drawing apps need fine grained cursor movement data.
But a test app to see how we could best solve that issue (and how BeOS compares) sounds like a good idea, definitely.
screenshot