Not P1.
I believe I know that problem, but until now I only saw that with very big
presentations. I will test as reported.
Related to Issue 107605?

For reported effect "In the normal view it becomes impossible ..." we already
have Issue 96487 

Steps how do reproduce analogue to attached sample file.

1. Create new presentation "without frills"
2. In Drawing Toolbar click button "From File" to insert picture from file
3. Select .png from sample kit and insert it linked.
4. click into Slides pane outside any slide
5. <cntrl>+<a> to slect all
   Slide 1 will gett border
6. <cntrl>+<c>, then <cntrl>+<v> to copy paste slide
   dialog appears
7. Select 'Insert after', <ok>
   New slied(s) will be inserted
8. redo from step 4 until you have 16 slides
9. redo from step 4 
   expected: everything works normal
   actual: after <cntrl>+<a> all slides get border as expected, but then border 
           disappears immediately, slides become unselected

In Slide Sorter Pane I see that impossibility to select all slides beginning
with 8 slides in it.

Indeed, it seems that the linked pictures cause the problem. If I start a new
test from step 1, but with embedded pictures, I did not see the problem even
with 256 slides or more.

Now I doubt that this problem is the same as in Issue 107605, because I see THAT
problem also for slides with embedded pictures.

I see the completely identical problem in the "Pages" pane in DRAW.

Worked fine with "2.4.1  Multilingual version German UI WIN XP:
[680m17(Build9310)]". 

Compared to 2.4, performance for copy paste slides is very very poor on my PC.

It's a serious problem, I see it as a 3.2 blocker.

Created attachment 66774 [details]
Test kit

Assigned owner and adjusted target

I'm not able to reproduce this issue on my xp workstation (amd dual core 2ghz,
3gb ram, office (non gamer) graphics card), even with 32 slides I have no
selection problem.

I'm currently debuging to see if there is something wrong with the graphic
caching...

AW->CL: Checked. Problem is that there is not really an asychronious loading for
linked graphics (and never was, even in old versions). When a linked graphic is
to be shown, ViewObjectContactOfGraphic::createPrimitive2DSequence uses the
helper impPrepareGraphicWithAsynchroniousLoading (instead of the synchronius
version). Independent from this, the async and the sync version uses
SdrGrafObj::ImpUpdateGraphicLink() to load the linked graphic. This works, but
uses internal stuff which calls SdrGraphicLink::DataChanged(..) which triggers a
SetChanged (correct for model data) which itself triggers a ActionChanged().

That ActionChanged() is triggered during repaint which leads to repaint races.
Besides that the PagePane View has IsSwapAsynchron() set to false, thus forcing
to load all the time anyways. Somehow for some count the loaded swapped linked
graphics get forced to be unloaded again. From that amount (ca. 6, settable as
graphics cache in the tools/settings somewhere) the whole system seems to need
longer and longer to get to an ending state.

The error is that indirectly an invalidate gets triggered during paint. I tried
to move

			if(rGrafObj.IsLinkedGraphic())
			{
				// update graphic link
				rGrafObj.ImpUpdateGraphicLink();
			}

from the preparators (impPrepareGraphicWithAsynchroniousLoading and
impPrepareGraphicWithSynchroniousLoading) to
ViewObjectContactOfGraphic::doAsynchGraphicLoading(), thus using
SdrGrafObj::ForceSwapIn() for synchronious load and
SdrGrafObj::ImpUpdateGraphicLink() for asynchronious, but outside paint. This
works better, but such a change is hard to predict.

my only idea for a fix would be to introduce a kind of resource manager (which I
already have in the queue for embedded sounds) which would detect that the same
graphic is used on every slide so it would be loaded once and only once.

But this would only fix a theoretical issue as usualy the user would have
multitple slides with different images (or put one image as a background image
on the master page which would get reused already).

I assign this issue to af for know as he is the maintainer of the slidesort

cl->af: please consult with aw if there is a possibility to have a fix for this
for OOo 3.2. If I recall correctly, this will be fixed anyway with your
slidesorter rework targeting at OOo 3.3++ ?

Created attachment 66868 [details]
Minimal patch to handle linked graphics like unlinked ones

AW: More infos:
- The problem does happen in slightly changed form in a DEV300 m66. The update
of the SlideSorter also gets slower, but gets to an end faster in comparison.
- The problem can not be avoided by increasing the tools/options/memory options
(or i could not find out, how to do that)
- With the proposed fix, the main view handling gets better. The SlidePane still
flickers and needs long time for update.

Guess: The main view gets better since the linked graphics can be loaded
asynchron with the proposed fix. The SlidePane still loads synchron since
IsAsynchronGraphicsLoadingAllowed() is set to false, thus still all graphics get
loaded all the time since the SlidePane repaint seems to repaint all visible
previews (may have to do with invalidates due to the loading again).

When loading synchronous for SlidePane this can be detected since the
ObectContact is a preview (true == GetObjectContact().IsPreviewRenderer()). In
that case, the graphic may be loaded only temporarily (as already done for
printing) in that case. Testing...

AW: Works much better with the 2nd change.
Tested with changes and many pages linked and non-linked graphics. Non-linked
are much faster, so i got the idea to use IsPreviewRenderer also in
impPrepareGraphicWithAsynchroniousLoading and
impPrepareGraphicWithSynchroniousLoading for rGrafObj.ForceSwapIn() calling
where rObjectContact.isOutputToPrinter() is checked. This does not change
anything, so removed again.
Adding patch so far.
Also will test another idea: Remove all Changed() and ActinChanged() calls from
ImpUpdateGraphicLink. Should not be needed nowadays...

Created attachment 67027 [details]
2nd minimal patch

AW: Indeed, when commenting in SdrGrafObj::SetGraphic(..) the lines
//	SetChanged();
//	BroadcastObjectChange();
all works well. The problem is indeed that SdrGrafObj::SetGraphic(..) gets
called from SdrGraphicLink::DataChanged(..).
Test shows that it's even enough to comment the 2nd line, thus the problem
really is the model change broadcast. The 1st line just leads to more repaints.
All this is triggered by SdrGrafObj::ImpUpdateGraphicLink() calls. AFAIK the
SlidePane refreshes on ModelChange the page preview for the page mentioned in
the hint. This re-creates the preview graphic and this needs to reload the graphic.
The tragedy here is that SdrGraphicLink::DataChanged(..) does not even INTEND to
change the model; it saves it's state and restores it in the most cases. This is
an UNWANTED model change (!)
What is (and was always) missing here is a SdrGrafObj::NbcSetGraphic(..). I
guess the one who added to rescue the mode state just did'nt want to add it.
Testing with adding it. Both commented lines will me moved to be not in the Nbc
method...

Created attachment 67032 [details]
3rd possible fix

AW: Added 3rd solution as patch.

AW: I think 3rd solution is the safest way and i propose it.
It only changes SdrGrafObj::SetGraphic to SdrGrafObj::NbcSetGraphic at
SdrGraphicLink::DataChanged where it is needed. There were model changes in
SdrGraphicLink::DataChanged before (when no graphic was set yet) but i think it
was wrong. Thus, this fix only changes the refreshes after swapin of a linked or
embedded graphic. None of the two situations justifies a model change. SlidePane
does not need a model-change based refresh, since it's preview was already
forced with correct swapped-in data and the preview stays valid.

AW: Still happening: the jumping around in the SlidePane, independent from
linked or non-linked graphics.

AW: This task handles two problems:
(a) The timing problem with linked graphics
(b) the 'jumping' when selecting in the SlidePane.

Since (a) is the critical part and i have a proposed fix and RC2 (which we
should use as a test) is in front of the door, I'll split this task:

- Takeover this task for (a) and add fix and task to CWS impress185 for RC2
- Wrtne another task for AF for (b)

AW: Submitted #i108126# as FollowUp.
AW: Adding patch tpo CWS impress185...

AW: Added and tested. Created files with linked, unlinked and mixed graphics,
all at least with 15 pages. Reloaded and exported to PDF. Works as expected.

AW->WG: Please verify.

Verified in CWS.

*** Issue 105273 has been marked as a duplicate of this issue. ***