(This is related to issue https://code.google.com/p/android/issues/detail?id=19057 in the sense that this seems to be Linux specific and related to Linux providing slightly different mouse and drag events (or in a different order) than on other platforms.)

Thanks for the video! Something is clearly very wrong...

I've installed Ubuntu 11.04 with OpenJDK and I'm running it in VMWare on the Mac -- but sadly the relative layout drag & drop behavior is normal for me -- I don't get the bugs you're showing in the video...

x86 or x86-64 version for the Ubuntu version you have installed? Could you try using Sun's JDK?

Still, thanks for looking at the bug :).

I was using the 64 bit version (because it's required to compile the android source base I think - last time when I set up a 32-bit environment I seem to remember my build failing with a message that the toolchain required 64 bit).

I'll try downloading the Sun JDK.   More importantly though, I'll see if my coworker Siva can reproduce this on his clean, not virtual, Linux machine tomorrow.

Thank you :), I am really glad for all the help and attention this issue has received! Keep up the great work :).

I was just able to reproduce the bug! Turns out I needed to run "Unity" as the window manager. I'll try to track this down, but in the meantime, turning off unity might be a workaround.

(No comment was entered for this change.)

Hmmmm.... I spoke too fast. I can't reproduce it again. Something weird is happening here.

...and we're back :)   Here's what I'm seeing: If I zoom in to 100% (by pressing the digit "1"), then drag & drop within the view works fine. If I zoom out to fit (by pressing "0"), then drag & drop stops working. I'm guessing this is related to some kind of coordinate translation error, but at least it's reproducible now.

Funny thing, I am using Unity 2D, but I do remember Ubuntu Classic having the same problem :).

Still, awesome news that you have been able to reproduce the bug :). Great job!

I will be at work for a few more hours today, so if you have something you want me to test, please fire away :).

What I'm seeing is that if the view is zoomed at 100%, then things work normally. However, if I zoom out (0, or -) then things appear to not work. However, if I drag and wait, after about 10 seconds (yeah, ten long seconds) then it updates. So it looks like all the drag and drop events are all there, but that something is really slowing things down to a crawl.

Can you try to see if that's the same thing you're seeing? In other words, if you drag, you notice that you're still seeing the old constraint suggestion, but if you keep waiting (lets say 20-30 seconds), does it eventually update to show the guidelines for the new position?

And if so, can you see what happens if you change the zoom level (try 1, 0, + and -) to see if this appears to be related for you as well?

I'm going to try to get a profiler working to see why things appear to be so slow in that scenario, but it would be great if you could confirm that you're seeing the same thing (works but extremely slow) as opposed to something else.

Some simple CPU sampling shows that image painting is taking a huge amount of time and it refers to "Cairo" in the stack frames; a little searching shows that this seems to be an advanced graphics library used on Linux (by SWT maybe via GTK) and apparently there are some performance issues around image scaling. We dynamically scale the canvas image. I'm going to investigate how prescaling it affects performance.

Yep, with prescaling the image using AWT and just doing a plain non-scaling paint of the image, I get smooth guideline feedback in zoomed versions of the relative layout too! I've gotta clean up the patch a bit though.

Fix pending in https://review.source.android.com/25703

Fixed in the development version of ADT.

Awesome job :) thank you. I have to say that I am really happy about the LinearLayout/SWT bug being fixed and now this one. all of that in addition to LogCat receiving  text wrapping in the DDMS tool make me really happy :).

Unfortunately, thanks to the proxies here, I cannot download the ADT package from git. Is it possible for you to apply the patch to the custom ADT plugin you made to test the LinearLayout fix or maybe there is not much to wait for the new ADT with both bugs fixed :)?

Have a nice day!

I've uploaded a build of ADT 12 + this fix (and the earlier drag & drop fix) here:
http://tools.android.com/download/android-eclipse-8.zip?attredirects=0&d=1

Hopefully you can confirm that it works, or perhaps there's a third Linux specific issue lurking somewhere :)

Awesome job indeed (and given the August's new "recent changes" page additions in the tools website, a lot of awesome stuff is coming :)).

This does solve the issue I have been having on this system related to RelativeLayouts. Dragging performance is a tiny bit sluggish, but it is more than good enough. Some of it has to be blamed on this PC, which is not exactly top of the line (Dual core Pentium 4@2.8 GHz, 4 GB of RAM).

Thanks so much for the effort and for fixing two bugs in such a short time (I should say three as logcat's text wrapping seems to be coming to DDMS soon too given https://code.google.com/p/android/issues/detail?id=18205#c5, so a lot of good things have improved in the ADT plugin for me :)).

I've uploaded a new snapshot here:
http://tools.android.com/download/android-eclipse-9.zip?attredirects=0&d=1

This fixes a resource leak in the new prescaling code.

 Issue 19554  has been merged into this issue.

Tested the last package, both LinearLayout and RelativeLayout seem to be working fine now: tried like 10-15 buttons with the RelativeLayout and performance seems to be good enough for normal operations :). Speed enhancements are always welcome though hehe :).

Thanks a lot for fixing these two bugs!

still not fixed for me
ubuntu 11.04 (with compiz and 121 dpi) on 1920x1200 (lenovo laptop)
eclipse 3.70
applied recommended zip, same symptoms... 

(No comment was entered for this change.)