Drag and drop optimization

[Wilco Greven]

On Tuesday 04 February 2003 13:08, Lubos Lunak wrote:
>  Strange, I get quite different numbers. It's 850MHz CPU, so it's notably
> faster, but also the improvements differ. When checking the whole
> QDragManager::move() method, findRealWindow() takes about 66% of the whole
> method. Your optimized version takes it down to 33%, thus saving half of
> the time. Perhaps you have many more windows open than I did, or maybe your
> testcase is wrong (at least, you shouldn't use random input, as that gives
> unreproducable results). 

I had a lot of windows open. This should be proportional to the number of 
times findRealWindow calls itself. Did you run the testprogram? I'm curious 
about what the exact results were. Or somebody else?

> Does your patch make a difference also in reality, e.g. when dragging in
> Konqy?

The improvement is most noticable when you drag a small icon, e.g. when 
dragging a mail in kmail. The difference is that the icon follows the cursor 
much more smoothly now. But the drag shapes in an iconview still lag behind 
the cursor. 

> > So far the biggest problem I can see is that the code relies on a NETWM
> > compliant window manager. For the rest it's hard to say because I don't
> > know X11 that well.
>
>  In order to make your code really work, you'd have to go back to
> XGetWindowAttributes and additionally check the map_state in the struct to
> be IsMapped. To check if the window manager supports the stacking property,
> you can use qt_net_supports().

Yes, I found out already that the stacking list also contained unmapped 
windows.

>  However, perhaps I have something better. Please try the attached patch.
> It should do two things: First, it makes a "hole" in the dragged pixmap, so
> XTranslateCoordinates() always finds the window under it, thus making
> findRealWindow() unnecessary. Second, if the app cannot catch up with the
> XServer sending the mouse move events, it tries to discard multiple move
> events. The second change doesn't actually help on my computer, because I
> have to try really hard to get CPU usage up to 100%, but on slower
> computers it should help (the CPU usage will be 100% too, but it won't
> demand more).

I tried out your patch. At first it didn't seem to be any better than the old 
situation. I could be that the first part (the hole patch), doesn't work as 
expected. Maybe Enter/Leave events are to blame in this case.

Then I combined the motion event compression with my own patch. Now the 
effect of the event compressing made a big difference. The drag shapes 
followed the mouse cursor much better.

>  In general, I don't think there can be done much more. This is a tough
> problem, actually. One more thing to do could be to have larger
> 'sameanswer' area (see the XDND spec), but I'm afraid that wouldn't be that
> trivial in Qt.

But deciding how big the answer rectangle is is up to the target. If the 
target wants to track the mouse (for showing dragshapes for example), the 
source has to keep sending position messages.

Maybe the drag shapes shouldn't be shown. They are pretty useless IMO. And 
there are other ways for the target to indicate that it accepts the drag. 
 
> I tried also some other things, like updating the icon position only every X
> ms, but that didn't look nice. And, actually, if the discarding of 
> superfluous move events will help to make it visuall acceptable without the
> icon lagging behind the cursor, I think there no need for further 
> optimizations.

Some other improvements are needed to make dnd really usable on my
computer. It happens pretty often that I drop something, before the target has 
had the time to check whether it accepts the drag. The result is that the 
drag doesn't work. 

-- 
Greetings,
Wilco