Created attachment 201152 [details]
sample png


I use Windows OS.
The text will not be blurred as in the description.
However, the background color becomes semi-transparent, and you can see the text behind it.
There were times when it was almost transparent for a while, but we could not find any reproduction procedure.
There should be a problem on Windows as well.

Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: fef47a8bcc8531e69ccea29f2db5929741e66a3e
CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded

Right, now I notice gen VCL also has the transparency.

The transparency is a result/feature using the new possibilities from https://gerrit.libreoffice.org/c/core/+/185417. It is hard to evaluate if that is preferred or not, more a question of taste. I did that only for the hovering mode and due to the fact that seeing more information is in principle always better. We would have to ask users or add this as a configurable option - or just ignore that we can do that now and remove it...
Will also take a look at the blur, but that is just for the surrounding lines (not the text, that is always INTENDED to be AntiAliased) display of the DrawShape...

(In reply to Armin Le Grand (allotropia) from comment #3)
> The transparency is a result/feature using the new possibilities from
> https://gerrit.libreoffice.org/c/core/+/185417. It is hard to evaluate if
> that is preferred or not, more a question of taste. I did that only for the
> hovering mode and due to the fact that seeing more information is in
> principle always better. We would have to ask users or add this as a
> configurable option - or just ignore that we can do that now and remove it...

Ok, then let's loop the UX team in.

(In reply to Armin Le Grand (allotropia) from comment #3)
> It is hard to evaluate if that is preferred or not...
https://fosstodon.org/@libodesign/114664737185162421 (poll runs 3 days)

Cool, thanks!

For the blur; Checked that using SYS+ALT+8 and -/0 to zoom in and see better - the outer bounds are on pixels already no blur there. Maybe that is an effect with the transparency (have already switched off locally?)...

As the topic of the shadow came up in the poll, there is a request for soft shadows: bug 138214

Ah - that could be done by just setting SoftShadow as attribute to the temp object that is used to create that floating comment's geometry - but that's a feature...

Poll has ended with
65% Yes, please make it semi-transparent
35% No, keep it opaque
The total number of participants was 17 (out of 952 followers on @libodesign)

=> keep the transparency

I however wonder if we can improve the situation by differentiating between sticky and temporary comments. If a comment is always shown it would be reasonable to get an idea of the content behind. But for a tooltip like popup on mouse hover we could use an opaque background.

I just stepped upon this issue in

Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 04744bbc9be4adca92eaba602b7a65c17f6b8dd7
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

(In reply to Heiko Tietze from comment #9)
> I however wonder if we can improve the situation by differentiating between
> sticky and temporary comments. If a comment is always shown it would be
> reasonable to get an idea of the content behind. But for a tooltip like
> popup on mouse hover we could use an opaque background.

I would do it *exactly* the other way around:

- sticky: The user has decided to see all comments, so actively decides to concentrate on these -> no interest in BG. In that case I would assume that transparency would indeed be distracting and not what the user wants.

- temporary/popup: Only short need to take a look at the comment. Slight transparency can help here for better orientation, e.g. see where else comments are that might be worth to take a look at. If these are covered by popup comment this is just not possible and hinder fast orientation. We can assume something like a 1st research phase for a newly opened document

(In reply to Armin Le Grand (allotropia) from comment #11)
> (In reply to Heiko Tietze from comment #9)
> > I however wonder if we can improve the situation by differentiating between
> > sticky and temporary comments. If a comment is always shown it would be
> > reasonable to get an idea of the content behind. But for a tooltip like
> > popup on mouse hover we could use an opaque background.
> 
> I would do it *exactly* the other way around:
> 
> - sticky: The user has decided to see all comments, so actively decides to
> concentrate on these -> no interest in BG. In that case I would assume that
> transparency would indeed be distracting and not what the user wants.

This is probably faster to render as well, right?

(In reply to Buovjaga from comment #12)
> This is probably faster to render as well, right?

Hard to say - depends on SDPR and HW support :) But in general: We should NOT argue with rendering speed when thinking about UI and UserExperience. The one is for satisfaction/Joy of the user, the other is a (solvable) technical problem. We should not let us hold back from that from my POV...

So if no complaints to comment 11 this one is as it should be...? Can I close?

(In reply to Armin Le Grand (allotropia) from comment #14)
> So if no complaints to comment 11 this one is as it should be...? Can I
> close?

I see your comment 6, but can't the blurriness really be fixed?

Invested: I did quite some changes, but indeed PixelSnap and Hairline *is* active in CairoPixelProcessor2D::processPolygonStrokePrimitive2D as it should be. The hairline is snapped to discrete pixels and drawn as hairline.

I also checked if all this is set in the ViewInformation2D used in OverlayManager::ImpDrawMembers, it is.

I still see that sometimes the left (blue) vertical line for a popup comment is not on a single pixel -> no idea why, have to think about it...

Taking a 2nd look, I have a suspicion...

Looks like it's indeed in the CairoSDPR: When using a sub-surface for pre-rendering something (needed for UnifiedTransparence, Transparence and XOR) the sub-surface gets an own temp PrimitiveRenderer with needed adapted ViewTransformation.
Up to now that less than a pixel distance (sub surface *has* of course to be pixel aligned) from the logical bounds seems to cause that in these sub-renderings the PixelSnap does not work. That also explains why it's only happening with using transparency - thus, a really good find in the end :-)

Need to investigate more, but should be doable...

Fit at https://gerrit.libreoffice.org/c/core/+/187928

Armin Le Grand (collabora) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/15a5d633fec3c3c62870ab4168a1886796350031

tdf#166734 CairoSDPR: use sub-pixel correct transformation

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Thanks, looks fine now. Feel free to close as fixed and let's backport.

Arch Linux 64-bit
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6566fdd608490e3fe25e7f5cae641cad00e181e5
CPU threads: 8; OS: Linux 6.15; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 16 July 2025

Armin Le Grand (collabora) committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/e09e660c74d5905dff5700c1017e481b608c3800

tdf#166734 CairoSDPR: use sub-pixel correct transformation

It will be available in 25.8.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

> Thanks, looks fine now. Feel free to close as fixed and let's backport.
Where to backport to, I am not so on the current versions, could you help please? Should not make problems technically.

(In reply to Armin Le Grand (collabora) from comment #23)
> > Thanks, looks fine now. Feel free to close as fixed and let's backport.
> Where to backport to, I am not so on the current versions, could you help
> please? Should not make problems technically.

The issue was in 25.8, so I backported it to libreoffice-25-8 branch.

(In reply to Buovjaga from comment #24)
> The issue was in 25.8, so I backported it to libreoffice-25-8 branch.

Thanks!