Closed Bug 12002 Opened 27 years ago Closed 26 years ago

Frames resize sluggisly

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jcarpenter0524, Assigned: pollmann)

References

(
URL
)

Details

Overview Description: Frames move sluggisly and won't stay where you release them Steps to Reproduce: - Go to debug/ViewerDemos/#9Frames from the menu - try to move frames by dragging frame bars Actual Results: Frames move sluggisly and won't stay where you release them Expected Results: Frames should move easily and stop where you release them Build Date & Platform Bug Found: 1999-08-16-09-M9 Linux only Additional Builds and Platforms Tested On: Frames work as expected on Win98, WinNT (Mac build isn't working today, will have to check later.)
Assignee: karnaze → pollmann
Reassigning to Eric.
Does not happen on Mac build 1999081708 Linux only problem
Summary: Frames move sluggisly and won't stay where you release them → [PP]Frames move sluggisly and won't stay where you release them
Putting on [PP] radar.
Status: NEW → ASSIGNED
Target Milestone: M10
Yup, this looks really bad... The slowness seems to be a general problem on Linux, but the I don't know why they aren't tracking mouse movements accurately. It seems like maybe not all needed mouse events are getting into the event system.
Target Milestone: M10 → M13
Hm, M10 is past.
QA Contact: beppe → petersen
Target Milestone: M13 → M16
Moving to M16.
Keywords: pp
Summary: [PP]Frames move sluggisly and won't stay where you release them → Frames move sluggisly and won't stay where you release them
*** Bug 33857 has been marked as a duplicate of this bug. ***
I recently fixed frameset splitters so that they won't end up in the wrong place. That fixes half of this bug. They are still sluggish. This is because of the way we implemented the splitter. It causes a reflow of all neighboring documents each time the slider is repainted during the drag. Nav's implmentation is much snappier.
Keywords: pp
Summary: Frames move sluggisly and won't stay where you release them → Frames move sluggisly
Looking at this with Troy, we noticed that it is much slower resizing framesets than the sum of reflowing each of the affected documents. There must be some other factor here causing us to do more work.
OS: Linux → All
Hardware: PC → All
Summary: Frames move sluggisly → Frames resize sluggisly
I just checked in a fix for this problem. We were not repainting between reflows as the splitter was dragged. I've added code to force a repaint, and this makes the movement much smoother, particularly on Windows. Closing this issues as FIXED. To verify, go to test 9 and drag one of the splitters. It should stay where you drop it and perceived performance should be improved. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Target Milestone: M16 → M15
Nice job pollmann!
Fixed in the May 22nd build.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.