Opened 19 years ago
Last modified 17 years ago
#271 closed bug
drag & drop is broken, can crash or deadlock app_server — at Version 9
Reported by: | marcusoverhagen | Owned by: | mmlr |
---|---|---|---|
Priority: | blocker | Milestone: | R1 |
Component: | - General | Version: | |
Keywords: | Cc: | diver | |
Blocked By: | Blocking: | ||
Platform: | All |
Change History (9)
comment:1 by , 19 years ago
Status: | new → assigned |
---|
comment:2 by , 19 years ago
blocked: | → 235 |
---|
comment:3 by , 19 years ago
Cc: | added |
---|
comment:4 by , 19 years ago
comment:5 by , 19 years ago
Are you sure it's caused by that? Usually, drag&drop messages are pretty tiny, and (un)flattening them even hundred times shouldn't be noticeable. (I haven't yet tried it, though :))
comment:6 by , 19 years ago
Under real hardware the delay is not noticeable but under QEMU there is one. Could come from the blending in HWInterface::_AdoptDragBitmap() as well though. The mouse moved message on the other hand certainly suffer from the constant unflattening even of tiny messages.
comment:7 by , 19 years ago
With the BMessage fix in hrev17101 negotiated drag & drop should now work too (making bitmap clips from ShowImage for example). I'll leave this bug open until I verified that there remain no locking issues.
comment:8 by , 18 years ago
I think there's no locking issues remains. The only thing is that first icon drag after Haiku boot doesn't work. After that everything is okey.
comment:9 by , 18 years ago
Description: | modified (diff) |
---|---|
Platform: | → All |
Simple drag & drop (like moving or dropping Tracker items) should work as of hrev17058. The negotiated drag & drop (making a bitmap clip from ShowImage) still seems to be broken. Note that we do not yet use (the faster) message delivery by shared area. This causes some flattening / unflattening that gives a noticable delay when initiating a drag.