Opened 19 years ago
Closed 17 years ago
#160 closed bug (fixed)
[Tracker] icons disappear when resizing column width
Reported by: | diver | Owned by: | stippi |
---|---|---|---|
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.
Attachments (1)
Change History (16)
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.
comment:8 by , 17 years ago
Thanks for the B_NO_POINTER_HISTORY hint Axel - seems Haiku doesn't respect it. New bug on the way.
comment:9 by , 17 years ago
Component: | - Applications → Servers/app_server |
---|---|
Owner: | changed from | to
The slow resizing problem is gone with hrev22025: I've changed the column resizing to work asynchronously instead of relying on GetMouse() (which still gets way more messages than on R5).
Parts of the columns still disappear on movement - it might be a problem of CopyBits(), so I'll let stippi try.
comment:10 by , 17 years ago
comment:11 by , 17 years ago
Ok, hrev23655 has it and hrev23670 doesn't. Must be hrev23663 :) https://lists.berlios.de/pipermail/haiku-commits/2008-January/010834.html
Please confirm.
follow-ups: 13 14 comment:12 by , 17 years ago
The bug is fixed, the only thing which remains is a high cpu usage while resizing a column, but i only tested it in vmwware. Should i open another bug for it?
follow-up: 15 comment:13 by , 17 years ago
Cc: | added |
---|
Replying to diver:
The bug is fixed, the only thing which remains is a high cpu usage while resizing a column, but i only tested it in vmwware. Should i open another bug for it?
Could this be because we handle things like B_NO_POINTER_HISTORY client side ? IOW: the messages are still sent, just filtered out.
comment:14 by , 17 years ago
Replying to diver:
The bug is fixed, the only thing which remains is a high cpu usage while resizing a column, but i only tested it in vmwware. Should i open another bug for it?
Well, imho, high cpu usage peak is normal when something needs redraw. More generally, if the cpu is idle, it is normal use it to the max to do the task as quickly as possible. So a cpu usage peak when cpu was idle doesn't tell us if the process is greedy. A better test is to check if a process is still responsive while the cpu is under load. I tested tracker window column resizing with charts eating 100% cpu, and it was still reasonably responsive :) (we could have a cpu eater test app, to try such things)
comment:15 by , 17 years ago
Cc: | removed |
---|---|
Resolution: | → fixed |
Status: | new → closed |
This bug has likely been fixed by hrev23688.
Replying to jackburton:
Could this be because we handle things like B_NO_POINTER_HISTORY client side ? IOW: the messages are still sent, just filtered out.
That will definitely have an impact, but it shouldn't be that large either (just doubles the number of mouse messages around in the worst case :-)). BeOS obviously uses a special shared area to propagate mouse messages, anyway.
BTW there is no need to add me to CC - I'm on the bug list, and will get a mail for every change, anyway :-)
screenshot