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 axeld)

If you open a folder (for example /boot/beos/apps) and try to resize columnlistview several times you'll notice that:

  1. Resizing is slow
  2. icons will disappear

To show icons again you have to redraw current view with another window.

Attachments (1)

resize_bug.PNG​ (11.6 KB ) - added by diver 19 years ago.
screenshot

Download all attachments as: .zip

Change History (16)

comment:1 by diver, 19 years ago

Summary: Dissapearing icons → Disappearing icons

by diver, 19 years ago

Attachment: resize_bug.PNG​ added

screenshot

comment:2 by axeld, 19 years ago

Cc: g.zachrisson@… added

comment:3 by axeld, 19 years ago

* Bug 492 has been marked as a duplicate of this bug. *

comment:4 by korli, 19 years ago

bug_group: → developers

comment:5 by diver, 18 years ago

Summary: Disappearing icons → [Tracker] icons disappear when resizing column width

comment:6 by tangobravo, 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 axeld, 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 tangobravo, 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 axeld, 17 years ago

Component: - Applications → Servers/app_server
Owner: changed from axeld to stippi

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 aldeck, 17 years ago

The bug was here in recent revisions, but i can't reproduce part 2 of the ticket, hrev23675 (vmware). For what is worth, i couldn't track wich revision solved it, but note that stippi's recent fixes hapened after (hrev23688).

Not sure about slowness though, but seems ok under vmware.

comment:12 by diver, 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?

in reply to:  12 ; comment:13 by jackburton, 17 years ago

Cc: axeld@… 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.

in reply to:  12 comment:14 by aldeck, 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)

in reply to:  13 comment:15 by axeld, 17 years ago

Cc: axeld@… 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 :-)

Note: See TracTickets for help on using tickets.