This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | GTK L&F: Drag&drop of windows is terribly slow | ||
|---|---|---|---|
| Product: | platform | Reporter: | Antonin Nebuzelsky <anebuzelsky> |
| Component: | Window System | Assignee: | _ tboudreau <tboudreau> |
| Status: | CLOSED WORKSFORME | ||
| Severity: | blocker | CC: | issues |
| Priority: | P2 | Keywords: | GTK, PERFORMANCE |
| Version: | 4.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 42937 | ||
|
Description
Antonin Nebuzelsky
2004-05-11 10:08:17 UTC
Is drag and drop slow, or is the visual feedback slow? There is a problem with this on Aqua too, due to hardware double buffering. The visual feedback. When you drag and move the window red areas appear and disappear with a huge latency. Any idea why the double buffering causes such a slowdown? It means that there's a hardware layer between when you say "paint this to the screen" and when it actually gets painted, and that hardware layer can choose to coalesce paints, etc., so you simply lose some repaints. I think it's more complicated in this case. Sometimes you can see the red polygon painted in sequence in the different places where you moved the mouse, so these paints don't seem to be coalesced. With the more recent GTK performance improvements, I can't find any problem with the performance of drag and drop. Yes, DnD with GTK L&F is now quite reasonable. |