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.