https://bugs.documentfoundation.org/show_bug.cgi?id=171556
Bug ID: 171556
Summary: lag when scrolling past scaled image on scaled page
view (cairo)
Product: LibreOffice
Version: 25.2.7.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Created attachment 206464
--> https://bugs.documentfoundation.org/attachment.cgi?id=206464&action=edit
page 1 very laggy
Open figures1.odt:
1. Set the view zoom (bottom right screen) to 50%, 100%, or 200%. The document
will scroll somewhat normally.
2. Set the view zoom to 80% or 180%. Now page 1 will hardly scroll while page 3
is still the same speed.
>From the image properties, page 1 contains an image that's scaled 59% of its
actual size, while page 3's image is scaled 100%.
I compiled libreoffice, cairo, and pixman with debuginfo and profiled the
cycles using perf. On both cases, the hottest path have
CairoPixelProcessor2D::paintBitmapAlpha called last before descending to cairo
and eventually pixman. The difference is when they reach
pixman_image_composite32, where case 1 will choose
fast_composite_scaled_bilinear_sse2_x888_8888_cover_SRC while case 2 will
choose the much slower general_composite_rect to run.
Just an idea of mine, maybe if we can detect if the document is moving while in
CairoPixelProcessor2D::paintBitmapAlpha, we can pass CAIRO_FILTER_FAST to
cairo_pattern_set_filter, and only pass CAIRO_FILTER_GOOD if the document is
stationary.
Version: 25.2.7.2 (X86_64) / LibreOffice Community
Build ID: 520(Build:2)
CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: kf6 (cairo+wayland)
Locale: id-ID (id_ID.utf8); UI: id-ID
Gentoo official package
Calc: threaded
--
You are receiving this mail because:
You are the assignee for the bug.
