If I use wxDC.SetUserScale() on wxGTK it doesn't draw any text.
It is fine up until the point that I change the scale from the
default of 1.0 to something less (I usually set it between
0.5 and 0.9).
On Windows it draws the text at reduced size as expected.
Roger
Roger Binns wrote:
If I use wxDC.SetUserScale() on wxGTK it doesn't draw any text.
It is fine up until the point that I change the scale from the
default of 1.0 to something less (I usually set it between
0.5 and 0.9).
Works for me. What version are you using?
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Works for me. What version are you using?
2.4.0.2.
If you want to see this in action, grab this one file:
It draws a continuous calendar (Alan Cooper style). The day label in each
cell is a fixed size. I draw then draw the events for each day. If these
run off the bottom then I shrink the user scale and try and draw the events
again. Run it on Windows and change the window size and you see this in
action. Run it on GTK and watch how the text is not drawn the moment the
text has to be shrunk.
I'm probably going to solve this by make a wxBitmap/MemoryDC large enough
for the entries and then scale that down into place.
I'm almost convinced that changing the user scale results in different
fonts being used rather than the specified font and the output pixels
getting shrunk down. You can see how the text looks like different
fonts and even bold at one point.
BTW when I am finished with this control and it is somewhat more mature
you are welcome to add it to wxPython. The difference between it and
the (two!!) existing controls is that this one is intended to
show information on the various days and allow the user to edit them
(I am actually going to have a seperate window with a day view for
editting stuff).
As for its design, that is culled straight from Alan Cooper's book
"About Face". He also has a very relevant article at
http://www.cooper.com/articles/art_goal_directed_design.htm
Roger
Roger Binns wrote:
Works for me. What version are you using?
2.4.0.2.
If you want to see this in action, grab this one file:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bitpim/bitpim/calendarcontrol.py
It draws a continuous calendar (Alan Cooper style). The day label in each
cell is a fixed size. I draw then draw the events for each day. If these
run off the bottom then I shrink the user scale and try and draw the events
again. Run it on Windows and change the window size and you see this in action. Run it on GTK and watch how the text is not drawn the moment the
text has to be shrunk.
There must be something else going on in your code that neither of is seeing right now as putitng dc.SetUserScale(s, s) in the wxScrolledWindow demo works fine for every value of s that I tried...
I'm probably going to solve this by make a wxBitmap/MemoryDC large enough
for the entries and then scale that down into place.I'm almost convinced that changing the user scale results in different
fonts being used rather than the specified font and the output pixels
getting shrunk down. You can see how the text looks like different
fonts and even bold at one point.
It can. By default fonts on X Windows are not scalable vector fonts, but fixed size bitmap fonts. It's only when you add freetype enabled font servers or somethign similar that you get scalable fonts, but even still apps that use the old style font specs don't always full advantage of the new capabilities. wxGTK tries to find the font that most closely matches the requested parameters and sometimes it will have to change font families to do that.
BTW, building wxGTK with gtk+ 2.x makes your sample work much better because it doesn't use the old style font specs but renders the scalable fonts directly. When I get some time I plan on running through all my tests again with wxGTK built with gtk+ 2.x and if all the problems I identified before have been fixed then I'll start making binaries for it.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
There must be something else going on in your code that neither of is
seeing right now as putitng dc.SetUserScale(s, s) in the
wxScrolledWindow demo works fine for every value of s that I tried...
I am writing into a wxMemoryDC if that makes a difference (ie not directly
to the screen). I'll experiment this evening with what happens when
drawing directly to the screen.
> I'm almost convinced that changing the user scale results in different
> fonts being used rather than the specified font and the output pixels
> getting shrunk down. You can see how the text looks like different
> fonts and even bold at one point.It can.
I was actually talking about Windows for that. I guess the big difference
is that I expect SetUserScale to render somehow at a scale of 1:1 and
then that output is scaled up or down. I certainly never expected
that if I request a 20 point font and the scale is 0.5 then a
(potentially different) 10 point font is found and used.
tests again with wxGTK built with gtk+ 2.x and if all the problems I
That will be nice.
Roger
> seeing right now as putitng dc.SetUserScale(s, s) in the
I've found a far worse problem with SetUserScale. Every time
you call it on Win9x, some GDI resource is consumed and is
not freed until the program exists. Using the system resource
meter I can watch my GDI resources go from 70% free to 10% free
(which is when Windows whines) in about a minute just by
sitting there resizing the window. (And when the app is
terminated, it never goes all the way back up again).
Before I stumbled onto this, I tried everything to figure out
what on earth was being leaked (assuming it was pens, brushes
or something). I still can't find out exactly what it is,
but it seems to be regions according to GDIUsage (and not very
conclusive proof at that).
I changed my code so that instead of calling SetUserScale,
it just takes my original font and creates a new one shrinking
the point size down by what I was calling SetUserScale with.
There is no longer any GDI resource leakage.
A nice side effect of this is that things work correctly
on wxGTK. (They are also eye wateringly slow on wxGTK. I assume
this is because it really is going off trying to find different
sized fonts each time, which means that it doesn't do that
when you use SetUserScale. I will fix this by using a font
cache.)
To reproduce, take this one file. Run it and keep resizing the Window.
Use system resource meter to see what is happening to GDI.
Revision 1.10 calls SetUserScale and revision 1.11 asks
for smaller font.
Another tool I used is GDIUsage from MSDN. This is for Win9x only:
There is an updated tool for Win2k/XP. It didn't show me anything useful
on my XP box.
Roger
Roger Binns wrote:
seeing right now as putitng dc.SetUserScale(s, s) in the
I've found a far worse problem with SetUserScale. Every time
you call it on Win9x, some GDI resource is consumed and is
not freed until the program exists. Using the system resource
meter I can watch my GDI resources go from 70% free to 10% free
(which is when Windows whines) in about a minute just by
sitting there resizing the window. (And when the app is
terminated, it never goes all the way back up again).
Please enter a bug report about this.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!