Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | performance: excessive reformatting in textboxes when mouse moves | ||
---|---|---|---|
Product: | Draw | Reporter: | hdu <hdu> |
Component: | code | Assignee: | Armin Le Grand <Armin.Le.Grand> |
Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | ahz001, Armin.Le.Grand, groucho266, hdu, issues, thomas.lange |
Version: | OOo 2.3 | ||
Target Milestone: | OOo 3.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 83491 |
Description
hdu@apache.org
2007-11-12 09:51:07 UTC
reassigning AW: I am sorry, but i cannot see any regresson on DrawingLayer side. It has always been like this (thanks to the people before me). What happens is pretty simple: - Mouse moves - PickAnything is the central old method to find out what's under the given position - To answer if we have a hit, the geometry of the object is needed - To get that for text, the DrawOutliner is used - Since the DrawOutliner is a single-incarnated, shared ressource, it needs to be filled newly with text data (OutlinerParaObject) - Since newly filled, it layouts the text - With the layouted text, the position is tested against hit Nothing has changed here from my side. Maybe sd::FuDraw::ForcePointer (or better: the application) calls PickAnything more often than in older versions? Maybe Text layout got slower or some buffering broke loose there? One of the next steps for reworking the office is the controller side what would include these interaction handlings. Forthe future this IsHit quastion can be answered by the text primitives which get layouted only once when the more complex primitive homing them changes. For the current situaton i see only one possibility: It makes no sense to try to hold the layouted OutlinerParaObject in the DrawOutliner to rescue the layout, this changes too often. The only thing i can think of is to buffer the last input to PickAnything() and it's result and just try not to call PickAnything too often. Of course this will not really make things better at real MouseMoves, but i guess it gets called often with the same position. AW->HDU: What also is needed is an error description to recreate it. The stack is nice, but under which circumstances does who have the impression that it is much slower suddenly than before? Please add information. Also adding some people to copy who may be involved. This issue is just a regular performance bug, not a regression. The performance bug became obvious because the CWS made reformatting a little bit more expensive, but Writer engine wasn't noticeably impacted, only the SdrView became sluggish. I don't understand why the SdrView would need to know what is under the mouse pointer for regular mouse move events, even when nothing is selected, dragged or clicked? @aw: The bugdoc is http://www.openoffice.org/nonav/issues/showattachment.cgi/49633/ i83491_tchinese.odg (the second attached file of issue 83491). Select the textbox then move the mouse over the text. AW->HDU: Very simple: As You can see with the stack, the correct MousePointer (Context-sensitive) is choosen. This depends on what is under the mouse position and is completely independent from selection. It's a visual user feedback so that it gets more clear what hapens when he presses the MouseButton. E.g. the drag mouse cursor is shown when over an object. So for text objects, it is necessary to check if we are over a Letter at every MouseMove. That's what always happened. You may check this with an selected ellipse without filling but with text, just hoover over it. This will even be extended in the future, think about hilighting the object under the cursor using a lightweight frame and evtl. displaying data. There is also e.g. the ToolTip option to show URL contents, etc. when over an object with URL. To the task itself: I see good chances for less layouting when we have the primitives since hit test will be possible with these then. Setting to enhancement and target 3.0. AW: Adding primitives tag since this can be enhanced with primitives... AW: Adapting target to primitive move to 3.1. . AW->TL: How are Your plans when You set it to started? Do You have a concrete plan to solve this? If Yes, please change owner, too. Actually I missed that I'm not the owner. ^^° Sorry! Thus if you don't think the problem lies within EditEngine or TextEngine you might as well keep it. But reformatting sounded like I should probably have a look into the issue and that's why I set it to started since I mistook me for the owner. Thus for the time being no plans or action taken so far or planned within the next few weeks. AW: With aw033 in DEV300 m30, the base for changing this is in the office: Make the HitTest use primitives. It is already used now for 3D objects and for 2D/3DBoundRect calculations. Needs to be used for 2D hit test, too. This is not trivial since HitTest diversifies hits on line, fill, text and other parts of objects which are not even always visible... AW: Moved to 3.2 AW: Evaluated. Current implementations at the SdrObjects (CheckHit) use only geometric knowledge, so this task will have to wait for #i99147# to be sure to have the evtl. invisible geometry available with the primitives. AW: This enhancement should be implemented with #i101872# which is in CWS aw065. I will check when it's integrated. AW: Done with DEV300 m52. HitTest uses the sequence of primitives now which gets formatted only once. Setting to fixed. AW: Closing. |