1) Fixed underflow when memoryDiff > memoryToFree
2) Use current viewport's page number instead of any visible page as
page from which distances are calculated
3) Renamed currentVieport to visibleRect, because the currentVieport is
a different thing
The new class TileNode represents a node in the tree structure
whereas Tile is just a data structure to store the pixmap and tile rect
and is used outside tiles manager.
The miss counter was taken away. Now the algorithm relies on the
distance between the tiles and the viewport.
Also the visibleRect() and setVisibleRect() methods were removed from
TilesManager since we now pass this information to
TilesManager::cleanupPixmapMemory()
Some requests may take a while to process in a highly zoomed region.
Since those requests are not yet finished, other requests to the same
region are likely to be made (specially if the user is scrolling fast)
and the generator will have to render the same region repeatedly.
Also when changing zoom rapidly some pixmaps can arrive at the tiles
manager when another request has already been posted. This pixmap is not
necessary anymore and should be discarded (the tiles manager will get a
new pixmap anyway).
Whenever the scrollbar value changes we request a new pixmap so we
always have an up to date viewport.
Unfortunately that can lead to unnecessary calls when zooming. That's
because the zoom event changes the value of each scrollbar but not all
at once. Instead one scrollbar value is changed after the other (leading
to two requests).
The problem here is that when the first request is made just one of the
scrollbars have its updated value while the other still carries the old
one. Previously that wasn't a big deal but now we depend on the correct
scrollbar values to get the visible viewport and thus request only the
visible tiles (and its whereabouts).
Without that change we're making requests to tiles that are not actually
visible and this only gets worse as the zoom level gets higher.
The visible region was set in the PixmapRequest only a tiles manager was
available. Because of that the generator could check if it was supposed
to used tiles by simply checking if its normalized rect was null.
However is good to know the visible region even when a tiles manager is
not present. This way if the request is big enough to start a tiles
manager we already know the visible region and can change the
PixmapRequest accordingly.
The splitting was only executed after the pixmap arrived the tiles
manager. That was bad and likely to lead to an unnecessary rendering in
the case of a big tile that would be split after all.
This also fixes a bug where some tiles weren't updated.
Most of the positioning calculations were taking into account the 'crop'
argument (which is a NormalizedRect) to execute some translations.
If not using tiles the value of crop were always the normalized bounding
box of the page, relative to the page itself. So translating by it is
essentially a noop.
When using tiles this argument represents the normalized viewport,
relative to the page. Although useful for the tiles manager, translating
by 'crop' is not necessary for any of those operations.
The machinery in KParts/QObject is already doing it and this way we don't get the
KXMLGUIClient::~KXMLGUIClient: 0x15637528 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
warning
I'm not sure if calling this a kdelibs bug yet or not though :D
BUGS: 261538
FIXED-IN: 4.9.1
As a side effect, this change fixes bug 303998, that caused a crash if
the part's widget was destroyed before the part itself, because
m_findBar had already been destroyed.
BUG: 303998
FIXED-IN: 4.9.0
If the panning action results in a request for new tiles, paint it as
well. The previous code wasn't taking the amount of scroll into
consideration to fetch the tile to be painted.
Fixes a bug that causes the extraction of a wrong bounding box:
If the request queue is not empty, signalPixmapRequestDone causes a new
pixmap request to be started, thus overwriting mPixmapGenerationThread's
mCalcBoundingBox before it is read by the if in the next line.
Now signalPixmapRequestDone is called after the bounding box is saved,
so that new requests are started only after all data from
mPixmapGenerationThread have been saved.
BUG: 257370
REVIEW: 105600
The call to FT_New_Face takes the address of the 'face' variable, whose type is a
typedef *something TF_Face;
The value of TF_Face (so a pointer to the properly filled font structure) s then
replaced inside the call of TF_New_Face; but when the latter function fails,
the value of 'face' is not reset and this leads to a crash in the distructor of
TeXFont_PFB.
So properly initialize TF_Face to 0, its address is valid, and the code works.
BUG: 303472
FIXED-IN: 4.8.5
Fabio D'Urso
Mailson Menezes
Albert Astals Cid
Yury G. Kudryashov
Script Kiddy
Luigi Toscano