This applies to all highlights, i.e. text selection too, are you sure we want that?

There's something weird going on with the drawing, i can easily get a bad state, see http://i.imgur.com/wDAQlcP.png which is https://ev.kde.org/reports/2017-en.pdf having searched for "a b c d e f " on the thumbnail bar in any word mode after scrolling up/down a few times.

This applies to all highlights, i.e. text selection too, are you sure we want that?

Are you sure we don't have that anyway? I get a darker-blue rectangle around text selections even without the patch.

There's something weird going on with the drawing, i can easily get a bad state, see http://i.imgur.com/wDAQlcP.png which is https://ev.kde.org/reports/2017-en.pdf having searched for "a b c d e f " on the thumbnail bar in any word mode after scrolling up/down a few times.

I cannot reproduce this, but I have a vague idea of what could be the cause. Does it go away if you surround the three new lines by

painter.save();
[patch]
painter.restore();

?

In D7662#143055, @sander wrote:

This applies to all highlights, i.e. text selection too, are you sure we want that?

Are you sure we don't have that anyway? I get a darker-blue rectangle around text selections even without the patch.

You sure? This is with the patch http://i.imgur.com/MWf1HF6.png and this is without it http://i.imgur.com/c5cgb7L.png

There's something weird going on with the drawing, i can easily get a bad state, see http://i.imgur.com/wDAQlcP.png which is https://ev.kde.org/reports/2017-en.pdf having searched for "a b c d e f " on the thumbnail bar in any word mode after scrolling up/down a few times.

I cannot reproduce this, but I have a vague idea of what could be the cause. Does it go away if you surround the three new lines by

painter.save();
[patch]
painter.restore();

?

No that doesn't help, i'd say the problem is that you're actually painting outside the box and thus things go bad, please double check, but for example, i searched for "e" on a document and without your patch the width of the highlight was 29 pixels, with your patch, it was 28 pixels of color + 2 pixels for the border, so there's 1 unaccounted for pixel that will break havoc with repaints.

See http://doc.qt.io/qt-5/coordsys.html for differences in coordinate system between aliased rectangles and anti-aliased rectangles.

Any progress on this?

I still cannot reproduce Albert's problems locally, but after reading Christoph's link (thanks!) I found out that I can move the upper left corner of the border one pixel towards the lower right without uncovering the yellow rectangle. Please somebody test whether the new patch still produces these artifacts.

Doesn't help, i'd even say it makes it a bit worse? https://i.imgur.com/z1uJ1Jf.png

Thanks for testing. However, I don't really know what do to now. Given that I am not very attached to this patch I might simply abandon it.

leave it around i'll try to have a look somewhen/sometime or maybe someone else picks it up.

The artifacts are caused by the fact that the highlight rectangle is drawn "inside the 'limits' paint region". When an highlight is only partially shown because it is at the top/bottom edges of the window, the border rectangle is drawn across the highlight (correctly). If the page is scrolled showing now the full highlight, the rectangle is drawn again around the whole highlight, but the previous rectangle is still there resulting in a horizontal line across the highlight.

This can be reproduced by slowly scrolling the page while an highlight is on the top/bottom border.

Changing line 406

QRect highlightRect = r.geometry( scaledWidth, scaledHeight ).translated( -scaledCrop.topLeft() ).intersected( limits );

to

QRect highlightRect = r.geometry( scaledWidth, scaledHeight ).translated( -scaledCrop.topLeft() );

produces the correct behavior (also when zooming).

It is just an empirical trial, so I am not sure if this breaks something else.

@sander Have you had the time to try the fix I suggested?

I would like to complete this feature, but we first need to figure out if what I propose does not break something else (possible).

@simgunz , I can't. Remember that I could never reproduce the artifacts that Albert is seeing. Therefore I cannot test whether your idea fixes them.

Have you tried also what I suggested to reproduce it? i.e. Position an highlighted word that match the search at the top boundary of the view so that it is half visible and then scroll to show it completely. (Just to confirm this is not reproducible)

I tried, but I still cannot reproduce it. I do see the spurious lines very very briefly when scrolling the hightlighted area into the viewport, but they are always removed.

Still, I like your modification from Feb 25, because I don't think that the border rectangle should be drawn across the highlight region if that region is only partially visible.

Ok, thanks for testing again. I re-tried your patch with the latest master (just to check that there weren't modifications that solved the problem) and I still can reproduce the error. With my modification it goes away. So let's wait for aacid to review the diff.

I arrive a little late, but testing Okular today I noticed a minor bug with your solution. If you slowly scroll the page by dragging it with the browse tool the upper/lower dark border are not drawn sometimes when the word is at the border of the page. See bug 398553. With the "solution" I proposed instead this was not happening IIRC.

Just tested again with my solution on top of sander one and the bottom border disappears, but not the upper one. Strange, I didn't remember this effect when I tested it months ago.