Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | disable anti-aliasing in slide sorter and slide pane | ||
---|---|---|---|
Product: | gsl | Reporter: | cno |
Component: | code | Assignee: | 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
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 AW: Added me to cc @ 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 :-) 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... 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). @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! @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. @pl: removing you from cc again - thanks for reading and so Request to "disable anti-aliasing in printer dialog preview" is invalid 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. @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? Reset assigne to the default "issues@openoffice.apache.org". |