Le 14/02/2018 à 14:51, Uwe Stöhr a écrit :
commit 1fb1b0a3f8429a12ce63b6daada1ac4ec4119889
Author: Uwe Stöhr
Date: Wed Feb 14 14:51:22 2018 +0100
UserGuide.lyx: document the removal of the pixmap cache for all languages
Dear Uwe,
Technically pixmap cache has not been removed yet from
Jean-Pierre Chrétien wrote:
> Russian UI translation has been recently completed, right?
Right.
> OK to commit?
Sorry, I didn't see your patch and committed myself... P
he preference "Tools->Preferences->Look&Feel->Screen Fonts->Use
+ pixmap cache to speed up font rendering" is not available anymore.
+ It was of dubious value and led to rendering issues.
+
* The following UI translations were dropped, because the lack of translation
On 12/09/2016 11:10 AM, Jean-Marc Lasgouttes wrote:
>
> Hello,
>
> The subject almost says it all. I am not sure that the pixmap cache (a
> different way of painting where the pixmaps corresponding to strings
> are remembered) is very useful these days, especially with my caching
Hello,
The subject almost says it all. I am not sure that the pixmap cache (a
different way of painting where the pixmaps corresponding to strings are
remembered) is very useful these days, especially with my caching patch
that also uses QTextLayout objects for painting.
Would somebody
On Mon, Oct 19, 2015 at 04:44:19PM +0200, Jean-Marc Lasgouttes wrote:
> I fixed it instead.
Seems like a reasonable alternative :)
> As often, it took a long time to find something that was obvious.
>
> So now pixmap caching sort of works (rendering is not as nice IMO). We can
> there fore leave
ze computations.
Agreed. But if this pixmap rendered text is ugly, we have one more reason for
getting rid of it. I'll try to make time for some profiling tomorrow.
Yes, another reason might be the memory consumption. In the past the pixmap
cache held glyphs. Now there are the text fragments Ly
Le 15/10/2015 09:20, Jean-Marc Lasgouttes a écrit :
Le 14/10/15 14:22, Stephan Witt a écrit :
Indeed. What about just dumping it? :p
I'm all for it.
I did some profiling. Pixmaps are indeed a little bit faster visually.
Here are the hard numbers
Without Pixmaps:
66% LyX
32% GuiWorkAre
Le 15/10/2015 14:47, Richard Heck a écrit :
On 10/15/2015 04:20 AM, Jean-Marc Lasgouttes wrote:
Le 14/10/15 14:22, Stephan Witt a écrit :
Indeed. What about just dumping it? :p
I'm all for it.
I did some profiling. Pixmaps are indeed a little bit faster visually.
Here are the hard numbers
On 10/15/2015 04:20 AM, Jean-Marc Lasgouttes wrote:
Le 14/10/15 14:22, Stephan Witt a écrit :
Indeed. What about just dumping it? :p
I'm all for it.
I did some profiling. Pixmaps are indeed a little bit faster visually.
Here are the hard numbers
Without Pixmaps:
66% LyX
32% GuiWorkAr
Le 14/10/15 14:22, Stephan Witt a écrit :
Indeed. What about just dumping it? :p
I'm all for it.
I did some profiling. Pixmaps are indeed a little bit faster visually.
Here are the hard numbers
Without Pixmaps:
66% LyX
32% GuiWorkArea::Private::updateScreen
12,6% BufferView::updateM
text
>>>> logo). I suspect some error in LyX's size computations.
>>>
>>> Agreed. But if this pixmap rendered text is ugly, we have one more reason
>>> for getting rid of it. I'll try to make time for some profiling tomorrow.
>>
>> Yes,
rid of it. I'll try to make time for some profiling tomorrow.
Yes, another reason might be the memory consumption. In the past the pixmap
cache held glyphs. Now there are the text fragments LyX draws in the cache.
Indeed. What about just dumping it? :p
JMarc
r
> getting rid of it. I'll try to make time for some profiling tomorrow.
Yes, another reason might be the memory consumption. In the past the pixmap
cache held glyphs. Now there are the text fragments LyX draws in the cache.
Stephan
Le 14/10/2015 08:02, Stephan Witt a écrit :
But I don't believe the effect of the clipped cached pixmaps is caused by this.
I gave not enough information - to spare email size the posted screen shots are
to small to see it - the effect isn't there globally. It happens on some line
ends and on
Am 14.10.2015 um 06:44 schrieb Jerry :
>
> On Oct 13, 2015, at 8:29 AM, Stephan Witt wrote:
>
>> Am 13.10.2015 um 16:43 schrieb Jean-Marc Lasgouttes :
>>
>>> Le 13/10/2015 12:32, Jerry a écrit :
Another difference is that the cached bitmaps (second line) do not use
subpixel ant
On Oct 13, 2015, at 8:29 AM, Stephan Witt wrote:
> Am 13.10.2015 um 16:43 schrieb Jean-Marc Lasgouttes :
>
>> Le 13/10/2015 12:32, Jerry a écrit :
>>>
>>> Another difference is that the cached bitmaps (second line) do not use
>>> subpixel antialiasing, the rendering method on OS X. (There used
Am 13.10.2015 um 16:43 schrieb Jean-Marc Lasgouttes :
> Le 13/10/2015 12:32, Jerry a écrit :
>>
>> Another difference is that the cached bitmaps (second line) do not use
>> subpixel antialiasing, the rendering method on OS X. (There used to be a
>> website explaining how Woz did this on the Apple
exuan is not that discouraging :)
If we cannot solve the pixmap cache issue we may disable it for the
alpha release, IMO.
Sure. But even before that, we can try to determine whether it gives any
performance boost. The 'fixed' version will not be faster IMO.
JMarc
Le 13/10/2015 12:32, Jerry a écrit :
Another difference is that the cached bitmaps (second line) do not use
subpixel antialiasing, the rendering method on OS X. (There used to be a
website explaining how Woz did this on the Apple II.) I don't know if
this affects the metrics.
Stephan, this is
On Oct 11, 2015, at 8:19 PM, Stephan Witt wrote:
> Stephan
>
Another difference is that the cached bitmaps (second line) do not use subpixel
antialiasing, the rendering method on OS X. (There used to be a website
explaining how Woz did this on the Apple II.) I don't know if this affects t
Am 12.10.2015 um 14:43 schrieb Stephan Witt :
> Am 12.10.2015 um 13:54 schrieb Jean-Marc Lasgouttes :
>
>> Le 12/10/2015 11:44, Stephan Witt a écrit :
>>> In fact it's the user who told me about the pixmap cache problem.
>>> I've asked him already if it&#
Am 12.10.2015 um 13:54 schrieb Jean-Marc Lasgouttes :
> Le 12/10/2015 11:44, Stephan Witt a écrit :
>> In fact it's the user who told me about the pixmap cache problem.
>> I've asked him already if it's slower than 2.1.4 but didn't get
>> an answer so far.
Le 12/10/2015 11:44, Stephan Witt a écrit :
In fact it's the user who told me about the pixmap cache problem.
I've asked him already if it's slower than 2.1.4 but didn't get
an answer so far.
I cannot look at pixmap cache stuff on linux since it is disabled there.
I can
this problem exists for all Lyx files I have). This problem goes
> way if I disable that option, but then the scrolling is very slow and choppy,
> and the font becomes very thin and less pleasant to read on a retina display.
> I'm using OS X El Capitan by the way.
In fact it's
Le 12/10/2015 11:03, Stephan Witt a écrit :
Unfortunately there are user reports telling LyX 2.2.0 is slow
(resp. slower than 2.1.4), IMHO. And I don't know anything about
Windows functionality and performance…
Do you pointers on that? Maybe we should collect them for analysis.
How did you de
Am 12.10.2015 um 10:39 schrieb Jean-Marc Lasgouttes :
> Le 12/10/2015 05:19, Stephan Witt a écrit :
>> If Q_WS_X11 and QPA_XCB are undefined it's possible to use
>> Qt's pixmap cache to speed up the drawing.
>
>> ATM, this seems to be broken (for HiDPI and Q
Le 12/10/2015 05:19, Stephan Witt a écrit :
If Q_WS_X11 and QPA_XCB are undefined it's possible to use
Qt's pixmap cache to speed up the drawing.
ATM, this seems to be broken (for HiDPI and Qt5 only?).
The placement of the text isn't correct while pixmap cache is enabled.
Doe
If Q_WS_X11 and QPA_XCB are undefined it's possible to use
Qt's pixmap cache to speed up the drawing.
ATM, this seems to be broken (for HiDPI and Qt5 only?).
The placement of the text isn't correct while pixmap cache is enabled.
Does it make sense to have this feature anymore on
Abdelrazak Younes wrote:
On 04/10/2008 08:29, Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
What should I do? -> Bugzilla?
Yes, that's the suggested action if no one reacts.
And please make sure to attach a backtrace if you can.
This is now
http://bugzilla.lyx.org/show_bu
On 04/10/2008 08:29, Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
What should I do? -> Bugzilla?
Yes, that's the suggested action if no one reacts.
And please make sure to attach a backtrace if you can.
Abdel.
Anders Ekberg wrote:
Is your menu OK after closing preferences,
No.
or could it be related to
http://bugzilla.lyx.org/show_bug.cgi?id=5168
No, it is not.
I can also reproduce the bug by manually putting
\use_pixmap_cache true
into the preferences file, and it also persists after a restart.
t;Screen Font -> Use Pixmap Cache
(\use_pixmap_cache true)
2) open UserGuide
3) view pdf
4) crash
On Lyx/Mac 1.6.0rc3 with a fresh clean user directory.
/Konrad
Konrad Hofbauer wrote:
> What should I do? -> Bugzilla?
Yes, that's the suggested action if no one reacts.
Jürgen
No attention.
What should I do? -> Bugzilla?
/Konrad
Konrad Hofbauer wrote:
1) Set Preferences-> Look&Feel ->Screen Font -> Use Pixmap Cache
(\use_pixmap_cache true)
2) open UserGuide
3) view pdf
4) crash
On Lyx/Mac 1.6.0rc3 with a fresh clean user directory.
/Konrad
1) Set Preferences-> Look&Feel ->Screen Font -> Use Pixmap Cache
(\use_pixmap_cache true)
2) open UserGuide
3) view pdf
4) crash
On Lyx/Mac 1.6.0rc3 with a fresh clean user directory.
/Konrad
Andre Poenitz wrote:
On Thu, Apr 24, 2008 at 09:22:02AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
Is there a way to disable the pixmap cache or at least to clean it
on shutdown?
I smell a privacy problem here...
You mean that other Qt apps running at the same
On Thu, Apr 24, 2008 at 09:22:02AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> Is there a way to disable the pixmap cache or at least to clean it
>> on shutdown?
>> I smell a privacy problem here...
>>
> You mean that other Qt apps running at the s
Andre Poenitz wrote:
Is there a way to disable the pixmap cache or at least to clean it
on shutdown?
I smell a privacy problem here...
You mean that other Qt apps running at the same time could access it?
We can of course clear it up on shutdown in the GuiApplication dtor.
Abdel.
Andre Poenitz wrote:
Is there a way to disable the pixmap cache or at least to clean it
on shutdown?
I smell a privacy problem here...
There should be check box in the preferences windows (Look and feel >
User interface).
Joost
Is there a way to disable the pixmap cache or at least to clean it
on shutdown?
I smell a privacy problem here...
Andre'
t; need a more simple explanation for the UserGuide. While googling I only
> > found that this cache is used for icons and bitmaps that are rendered from
> > SVG-images in KDE 4.
> > So we only use it for fonts? Then we shouldn't name it "pixmap" but better
> > &
On Nov 5, 2007, at 3:26 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Bennett Helm wrote:
This works for me with 1.6svn (I'm not blind!), but I still
don't notice any difference with 1.5svn.
This is strange. The fix is identical in branch and trunk.
Yep. And I verified again that
> For the user guide, just write something like:
many thanks
Uwe
t this cache is used for icons and bitmaps that are rendered from
> SVG-images in KDE 4.
> So we only use it for fonts? Then we shouldn't name it "pixmap" but better
> "screen font cache". Opinions?
On the technical side, pixmap cache is more appropriate (read the
Uwe Stöhr wrote:
> Except for the icons part, it's correct. This cache is only about
text painting.
> Look at the status.15x entry:
>
> - The pixmap cache that was introduced in LyX 1.5.2 to improve
performance
> can now be switched on and off in Preferences, sin
> Except for the icons part, it's correct. This cache is only about text
painting.
> Look at the status.15x entry:
>
> - The pixmap cache that was introduced in LyX 1.5.2 to improve performance
> can now be switched on and off in Preferences, since it might decrease
&
Jürgen Spitzmüller wrote:
Bennett Helm wrote:
This works for me with 1.6svn (I'm not blind!), but I still don't
notice any difference with 1.5svn.
This is strange. The fix is identical in branch and trunk.
Yep. And I verified again that the cache is enabled/disabled in sync
with with the c
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
I need to describe this in the docs. What exactly does the pixmap?
Is this description correct?:
B.1.1.6 Pixmap Cache
The option Enable Pixmap Cache activates a cache for screen fonts and
icons like toolbar buttons. Using this cache improves the speed
Bennett Helm wrote:
> This works for me with 1.6svn (I'm not blind!), but I still don't
> notice any difference with 1.5svn.
This is strange. The fix is identical in branch and trunk.
Jürgen
difference anyway. I guess it depends
on the
font used too.
But if it's still "bad", we have to investigate. What do other
people say who
complained about the missing subpixel hinting? Is it better for you?
It works as expected here. With pixmap cache enabled subpixel
renderi
Am 04.11.2007 um 13:46 schrieb Jürgen Spitzmüller:
Stefan Schimanski wrote:
It works as expected here. With pixmap cache enabled subpixel
rendering is off, with the option switched to off the subpixel
rendering is working fine again.
Glad to hear that. You're on Mac, right?
Yes.
Stefan
Stefan Schimanski wrote:
> It works as expected here. With pixmap cache enabled subpixel
> rendering is off, with the option switched to off the subpixel
> rendering is working fine again.
Glad to hear that. You're on Mac, right?
Jürgen
too.
But if it's still "bad", we have to investigate. What do other
people say who
complained about the missing subpixel hinting? Is it better for you?
It works as expected here. With pixmap cache enabled subpixel
rendering is off, with the option switched to off the subpixel
Abdelrazak Younes wrote:
> > (In switching, I quit and restarted LyX each time, not knowing whether
> > that would make a difference or not.)
> >
> > Am I just blind?
>
> I never was able to see the difference anyway. I guess it depends on the
> font used too.
But if it's still "bad", we have to i
Uwe Stöhr schrieb:
I need to describe this in the docs. What exactly does the pixmap?
Is this description correct?:
B.1.1.6 Pixmap Cache
The option Enable Pixmap Cache activates a cache for screen fonts and icons like toolbar buttons.
Using this cache improves the speed performance of LyX
Bennett Helm wrote:
On Nov 2, 2007, at 7:15 AM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And I confirm that it works fine.
Good. I applied the thing to branch. Will do trunk later.
I just updated and recompiled branch, and found the preference setting,
but I don't notice any dif
On Nov 2, 2007, at 7:15 AM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
And I confirm that it works fine.
Good. I applied the thing to branch. Will do trunk later.
I just updated and recompiled branch, and found the preference
setting, but I don't notice any difference whether it's
> I applied the thing to branch.
I need to describe this in the docs. What exactly does the pixmap? Is there a
wiki-page about this?
regards Uwe
Abdelrazak Younes wrote:
> And I confirm that it works fine.
Good. I applied the thing to branch. Will do trunk later.
Jürgen
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
The attached patch implements a pref option to enable the pixmap
cache on
Windows and the Mac (it is now disabled by default).
I cannot really test, since I'm on Linux. Could someo
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
The attached patch implements a pref option to enable the pixmap
cache on
Windows and the Mac (it is now disabled by default).
I cannot really test, since I'm on Linux. Could someone do this and
check
th
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
The attached patch implements a pref option to enable the pixmap cache on
Windows and the Mac (it is now disabled by default).
I cannot really test, since I'm on Linux. Could someone do this and check
that it works?
-bool
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
It can be done easily, if needed.
I think you should do it.
Sorry, I mean you should implement the option in trunk first and then
backport it to branch.
Abdel.
Juergen Spitzmueller wrote:
The attached patch implements a pref option to enable the pixmap cache on
Windows and the Mac (it is now disabled by default).
I cannot really test, since I'm on Linux. Could someone do this and check
that it works?
-bool const usePixmapCache = USE_PIXMAP_
The attached patch implements a pref option to enable the pixmap cache on
Windows and the Mac (it is now disabled by default).
I cannot really test, since I'm on Linux. Could someone do this and check
that it works?
I do not plan to forwardport this to trunk ATM, since Abdel maybe has
diff
.
Could that be a command line option?
Why not a normal preference? The cache could be disabled by default
but users with old computers can enable it for better performance with
less font quality.
Some general questions about the whole pixmap cache approach:
1. How many pixmaps are cached
Joost Verburg wrote:
Andre Poenitz wrote:
On Wed, Oct 17, 2007 at 05:57:12PM +0200, Stefan Schimanski wrote:
The patch is simple: Open GuiPainter.cpp. At the top is a #define
macro which can be set as you like to enable or disable the cache.
Could that be a command line option?
Why not a n
On Wed, Oct 17, 2007 at 08:07:29PM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
> >On Wed, Oct 17, 2007 at 05:57:12PM +0200, Stefan Schimanski wrote:
> >>The patch is simple: Open GuiPainter.cpp. At the top is a #define
> >>macro which can be set as you like to enable or disable the cache.
command line option?
Why not a normal preference? The cache could be disabled by default
but users with old computers can enable it for better performance
with less font quality.
Some general questions about the whole pixmap cache approach:
1. How many pixmaps are cached?
2. I guess the main
Andre Poenitz wrote:
On Wed, Oct 17, 2007 at 05:57:12PM +0200, Stefan Schimanski wrote:
The patch is simple: Open GuiPainter.cpp. At the top is a #define
macro which can be set as you like to enable or disable the cache.
Could that be a command line option?
Why not a normal preference? The
Stefan Schimanski wrote:
The patch is simple: Open GuiPainter.cpp. At the top is a #define macro
which can be set as you like to enable or disable the cache.
Thanks! Disabling the cache makes everything look normal again. Much
better for my eyes :)
Joost
On Wed, Oct 17, 2007 at 05:57:12PM +0200, Stefan Schimanski wrote:
> The patch is simple: Open GuiPainter.cpp. At the top is a #define
> macro which can be set as you like to enable or disable the cache.
Could that be a command line option?
Andre'
Joost Verburg wrote:
Abdelrazak Younes wrote:
On Windows, enabling or disabling the cache has strictly no effect on
my LCD screen.
Are you sure about this? I have ClearType enabled (the standard Windows
anti-aliasing which does sub-pixel rendering) but the fonts in LyX do
not look correctly.
The patch is simple: Open GuiPainter.cpp. At the top is a #define
macro which can be set as you like to enable or disable the cache.
Stefan
Am 17.10.2007 um 16:18 schrieb Joost Verburg:
Stefan Schimanski wrote:
After compiling the latest trunk (with the pixmap cache
optimization in the
Abdelrazak Younes wrote:
On Windows, enabling or disabling the cache has strictly no effect on my
LCD screen.
Are you sure about this? I have ClearType enabled (the standard Windows
anti-aliasing which does sub-pixel rendering) but the fonts in LyX do
not look correctly. I'm quite certain tha
Stefan Schimanski wrote:
After compiling the latest trunk (with the pixmap cache optimization in
the GuiPainter) I noticed a very bad font rendering. I attached two
pictures, the first showing trunk with normal antialiasing, the right
showing direct font rendering with the pixmap cache
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Does it sound reasonable to check for overlaps of the text pixmaps,
to put the background color into the pixmap signature and to use
non-transparent bitmaps instead?
Seems the obvious way to go.
But I guess we will have problem to make this w
Stefan Schimanski wrote:
Am 15.10.2007 um 22:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
This should explain it on Mac:
http://michelf.com/weblog/2006/subpixel-antialiasing-achilles-heel/
Here is the important part:
That said, I think Quartz is pretty smart because subpixel
a
Am 15.10.2007 um 22:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
This should explain it on Mac:
http://michelf.com/weblog/2006/subpixel-antialiasing-achilles-heel/
Here is the important part:
That said, I think Quartz is pretty smart because subpixel
antialiasing works on sem
Stefan Schimanski wrote:
This should explain it on Mac:
http://michelf.com/weblog/2006/subpixel-antialiasing-achilles-heel/
Here is the important part:
That said, I think Quartz is pretty smart because subpixel
antialiasing works on semitransparent backgrounds, like menus pulling
out from
This should explain it on Mac:
http://michelf.com/weblog/2006/subpixel-antialiasing-achilles-heel/
Here is the important part:
That said, I think Quartz is pretty smart because subpixel
antialiasing works on semitransparent backgrounds, like menus
pulling out from the menu bar. It implem
Am 15.10.2007 um 12:15 schrieb Stefan Schimanski:
Well, maybe not so wired. Just a guess: the backing pixmap is not
transparent. The cache uses transparent pixmaps and as I wrote in
the last posting, I think this makes a difference.
I removed the transparent fill command. Still there is no
On Mon, Oct 15, 2007 at 11:40:08AM +0200, Abdelrazak Younes wrote:
> Stefan Schimanski wrote:
> >Hi!
> >
> >After compiling the latest trunk (with the pixmap cache optimization in
> >the GuiPainter) I noticed a very bad font rendering. I attached two
> >pictures,
Hans Meine wrote:
Am Montag, 15. Oktober 2007 12:03:35 schrieb Stefan Schimanski:
This is really bizarre in that, even when the cache is disabled, we
still uses a backing QPixmap. What you are saying means that
painting a QPixmap onto the screen does not render the same as
painting it onto
Am Montag, 15. Oktober 2007 12:03:35 schrieb Stefan Schimanski:
> > This is really bizarre in that, even when the cache is disabled, we
> > still uses a backing QPixmap. What you are saying means that
> > painting a QPixmap onto the screen does not render the same as
> > painting it onto anot
Well, maybe not so wired. Just a guess: the backing pixmap is not
transparent. The cache uses transparent pixmaps and as I wrote in
the last posting, I think this makes a difference.
I removed the transparent fill command. Still there is not sub-pixel
rendering. Strange.
Stefan
PGP.sig
ordered. See: http://en.wikipedia.org/wiki/Subpixel_rendering
<>
the first showing trunk with normal antialiasing, the right
showing direct font rendering with the pixmap cache disabled, i.e.
Qt is using sub-pixel rendering. On a CRT there is no difference
at all, on an LCD the le
Stefan Schimanski wrote:
Hi!
After compiling the latest trunk (with the pixmap cache optimization in
the GuiPainter) I noticed a very bad font rendering. I attached two
pictures,
Maybe I'm blind but I don't see big differences between the two pictures.
the first showing trunk w
Hi!
After compiling the latest trunk (with the pixmap cache optimization
in the GuiPainter) I noticed a very bad font rendering. I attached
two pictures, the first showing trunk with normal antialiasing, the
right showing direct font rendering with the pixmap cache disabled,
i.e. Qt is
90 matches
Mail list logo
