Issue 112228

Summary: disable anti-aliasing in slide sorter and slide pane
Product: gsl Reporter: cno
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, issues
Version: OOo 3.2   
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description cno 2010-06-08 21:08:09 UTC
As er subject: pls disable anti-aliasing in printer dialog preview, slide sorter
and slide pane.

For quite some files it is anoying slow to completely unworkable.

Related are:
 - issue 105116
 - issue 105655
 - issue 108267

Thanks,
Cor
Comment 1 Armin Le Grand 2010-06-09 11:07:52 UTC
AW->cornouws: Double to #i106692#.

As can be seen there, on most systems the speed AAed and non-AAed is nearly
similar. This shows that it is technically possible and a question of support,
often from the underlying OS/graphic subsystems (e.g. XRender implementation).
Thus, it should be the goal for all systems, not to switch AA off, but to find
the reason for bad AA performance on that system.

I am pretty sure there will be no majority (esp. when AA is fast on most
systems) who wants no AA in SlideSorter previews. What would happen is that You
get tasks like 'AA in slide previews and during interactions broken' immediately.

Of course it would be possible to add another switchable option; but besides
that this is for a minority of people and creates more administrative costs and
blurs the UI more, it also binds ressources which would be more useful spent in
looking for the real problem.

The goal needs to be to get better speed with AA on systems which have problems
with it, not to switch it off. As can also be seen with #i106692#, this seems to
work and being possible on more and more systems; also seems to be dependent on
the distributions (?) sometimes, for whatever reasons.

So, from my side: -1
Comment 2 Armin Le Grand 2010-06-09 11:09:19 UTC
AW: Added me to cc
Comment 3 cno 2010-06-09 22:43:41 UTC
@ armin:
thanks for your patient and detailed explanantion (here and on other places) and
of course the work on the related issues.

Idealy: yes AA should be active, no more options :-)  and it should work happily
and fine on all systems/OSses/Video drivers and so on.

But if you ask me to find out how I can tweak my video driver or so... I have to
start study that area.

So I am just a bit afraid that for many peple the ideal situation is not there
by default and also not within the reach of their skills.

For the moment:
 - I will do some more tests with documents I find here and there (106692 for
exmaple);
 - keep my eyes and ears open.
 - consider polling UX ?

But wit this issue you may count me in as a critical follower :-)
Comment 4 Armin Le Grand 2010-06-10 11:19:08 UTC
AW: I agree that this is a problem for people who have no idea how to solve the
problem; OTOH OOo cannot stand in for every problem caused by HW- or SW-base. We
already try to do as much as possible and often work around issues which are not
ours, but there is a border not to cross; errors have to be fixed where they
emerge; else You will often see the inverse error when 'worked around' in OOo
and suddenly fixed in the root cause system part.
For this task, it would mean that the user's system is capable of fast AA one
day, but will still show non-AAed since it was switched off by the user. Don't
tell me that a standard user will try to switch it on again from time to time.
We still have the possibility o swich AA completely off in that case; why did we
left in that option, though?
As an application on the end of the food chain You often get tasks 'it's not
working' and when looking why the rason is not OOo at all; nonetheless people
blame OOo for it. Sometimes i just wish people would more often write tasks to
the source of the problem (after identifying or being told). Maybe it's just
easier to write a task for OOo...
Comment 5 philipp.lohmann 2010-06-15 11:55:24 UTC
I'll pass this issue to the impress team so they can fix the problem for the
slide sorter and slide pane.

I think there is no antialiasing involved in the print preview (the preview
window is draw from a downscaled bitmap to avoid formatting issues - see issue
104784 - which produces an effect similar to antialiasing).
Comment 6 cno 2010-06-16 21:55:09 UTC
@pl (sorry for putting you here in CC)

have you tried with attachment 65183 [details] from issue 105655?
It takes 10-15 secs to finish opening print dialog with AA.

(Which is much less then opening the document > 20 secs)

Without AA it takes < 1 sec to finish opening print dialog!


Comment 7 cno 2010-06-28 13:11:52 UTC
@pl in DEV300m83 starting the print dialogue takes -only- about 5-6 seconds.
but indeed, it looks related more to a general repaint problem, than the print
preview.
When I add two empty pages and put the cursor at the bottom, start print
dialoge, it pop ups immediately, although it does show the page with the fontwork.
Comment 8 cno 2010-06-28 13:12:36 UTC
@pl: removing you from cc again - thanks for reading and so
Comment 9 cno 2010-06-28 13:14:18 UTC
Request to  "disable anti-aliasing in printer dialog preview" is invalid
Comment 10 kswenson 2011-01-28 19:28:05 UTC
I would certainly benefit from a way to turn of AA no the slide sorter and slide
pane.

I have a modern system running the proprietary nvidia drivers and the sorter and
pane are unusable for drag and drop.

If I turn off AA altogether, my slides look like crap.
Comment 11 groucho266 2011-01-31 15:57:54 UTC
@kswenson: Can you be more specific about your problem?  You are observing this
on Linux?  How is the slide sorter unusable for drag and drop (render speed,
time it takes to insert a slide, result is not correct)?  Does turning off AA
improve working with the slide sorter?
Comment 12 Marcus 2017-05-20 11:35:12 UTC
Reset assigne to the default "issues@openoffice.apache.org".