LCD vs CRT Monitors Issues (!)

Andrea_Gavana · September 29, 2007, 4:56pm

Hi All,

I have been working for a while to update and check FlatMenu for a
(possible) inclusion of this module inside wx.lib for the next
release, depending on Robin's opinion.
With the kind suggestions from Tim Morton, who reported bugs and
limitations of FlatMenu, I think I have almost kicked out all the
issues.
However, one problem still remains, and it is related to a difference
between LCD and CRT monitors. I have an LCD monitor at home and a CRT
at work, so I could verify the issue. In Tim's words:

"However, I have found another peculiar problem with the Flatmenu
display on LCD monitors. I normally use a Viewsonic 19in CRT monitor
and the display of the menu when it is activated with a mouseover is
fine, but when I view it on (two different) LCD monitors the menu text
becomes rough, jagged and somewhat bold. It remains when the mouse
leaves. The whole app must be resized horizontally to refresh it back
to normal appearence."

I attach the screenshots Tim sent to me to demonstrate the problem. I
have absolutely no idea why the 2 kind of monitors should behave
differently in this case, but I though that someone more knowledgeable
than me might shed some light on this problem.

Moreover, I still have no idea on the behavior of FlatMenu on Mac, so
if there is one (or more) kind soul who will try it on a Mac and
report back problems and issues, I will be glad to address them. For
all users, the latest FlatMenu release can be found in the usual
place:

http://xoomer.alice.it/infinity77/main/freeware.html#flatmenu

Thank you for your suggestions.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Stef_Mientki · September 29, 2007, 5:07pm

isn't this the "clear type" setting, which on windows can both be done software,
and most LCD monitors also support a hardware setting.
In Linux I think it's done all the time

cheers,
Stef

Andrea Gavana wrote:

···

Hi All,

I have been working for a while to update and check FlatMenu for a
(possible) inclusion of this module inside wx.lib for the next
release, depending on Robin's opinion.
With the kind suggestions from Tim Morton, who reported bugs and
limitations of FlatMenu, I think I have almost kicked out all the
issues.
However, one problem still remains, and it is related to a difference
between LCD and CRT monitors. I have an LCD monitor at home and a CRT
at work, so I could verify the issue. In Tim's words:

"However, I have found another peculiar problem with the Flatmenu
display on LCD monitors. I normally use a Viewsonic 19in CRT monitor
and the display of the menu when it is activated with a mouseover is
fine, but when I view it on (two different) LCD monitors the menu text
becomes rough, jagged and somewhat bold. It remains when the mouse
leaves. The whole app must be resized horizontally to refresh it back
to normal appearence."

I attach the screenshots Tim sent to me to demonstrate the problem. I
have absolutely no idea why the 2 kind of monitors should behave
differently in this case, but I though that someone more knowledgeable
than me might shed some light on this problem.

Moreover, I still have no idea on the behavior of FlatMenu on Mac, so
if there is one (or more) kind soul who will try it on a Mac and
report back problems and issues, I will be glad to address them. For
all users, the latest FlatMenu release can be found in the usual
place:

http://xoomer.alice.it/infinity77/main/freeware.html#flatmenu

Thank you for your suggestions.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Stephen_Hansen · September 29, 2007, 6:20pm

Moreover, I still have no idea on the behavior of FlatMenu on Mac, so
if there is one (or more) kind soul who will try it on a Mac and

report back problems and issues, I will be glad to address them. For
all users, the latest FlatMenu release can be found in the usual
place:

It dun’ work, because Mac’s don’t appear to have a wx.PopupWindow. I tried to see if I could work around/fix-- but don’t have any idea what wxPopupWindow does. Which is interesting because while being a C++ wx class apparently, its not in my C++ documentation.

Traceback (most recent call last):
File “FlatMenuDemo.py”, line 537, in ?
main()
File “FlatMenuDemo.py”, line 531, in main
frame = FlatMenuDemo(None, -1)
File "FlatMenuDemo.py
", line 144, in init
self.CreateMenu()
File “FlatMenuDemo.py”, line 174, in CreateMenu
fileMenu = FM.FlatMenu()
File “/Users/ixokai/Desktop/FlatMenu/FlatMenu.py”, line 2748, in init

FlatMenuBase.__init__(self)

File “/Users/ixokai/Desktop/FlatMenu/FlatMenu.py”, line 1839, in init
ShadowPopupWindow.init(self)
File “/Users/ixokai/Desktop/FlatMenu/FlatMenu.py”, line 1465, in init

wx.PopupWindow.__init__(self, parent)

File “//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.8-mac-unicode/wx/_windows.py”, line 1736, in init
windows.PopupWindow_swiginit(self,windows.new_PopupWindow(*args, **kwargs))

NotImplementedError

And thinking about it, it’s so bizarrely wrong even if it does work! Having menu bars appear on a mac, that is. If this was added I’d almost certainly use it in our application-- but use a thin wrapper around it, such that on a mac it just totally bypasses all of FlatMenu and creates a standard menubar for the window, but on the PC it makes a FlatMenu. I don’t know how closely you’re following the menubar API so how easy that’d be, but IMHO that’s how I’d use it on a mac

–Stephen

Andrea_Gavana · September 29, 2007, 9:54pm

Hi Stephen,

> Moreover, I still have no idea on the behavior of FlatMenu on Mac, so
> if there is one (or more) kind soul who will try it on a Mac and
> report back problems and issues, I will be glad to address them. For
> all users, the latest FlatMenu release can be found in the usual
> place:

It dun' work, because Mac's don't appear to have a wx.PopupWindow. I tried
to see if I could work around/fix-- but don't have any idea *what*
wxPopupWindow does. Which is interesting because while being a C++ wx class
apparently, its not in my C++ documentation.

Traceback (most recent call last):
  File "FlatMenuDemo.py", line 537, in ?
    main()
  File "FlatMenuDemo.py", line 531, in main
    frame = FlatMenuDemo(None, -1)
  File "FlatMenuDemo.py ", line 144, in __init__
    self.CreateMenu()
  File "FlatMenuDemo.py", line 174, in CreateMenu
    fileMenu = FM.FlatMenu()
  File "/Users/ixokai/Desktop/FlatMenu/FlatMenu.py", line
2748, in __init__
    FlatMenuBase.__init__(self)
  File "/Users/ixokai/Desktop/FlatMenu/FlatMenu.py", line
1839, in __init__
    ShadowPopupWindow.__init__(self)
  File "/Users/ixokai/Desktop/FlatMenu/FlatMenu.py", line
1465, in __init__
    wx.PopupWindow.__init__(self, parent)
  File
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.8-mac-unicode/wx/_windows.py",
line 1736, in __init__

_windows_.PopupWindow_swiginit(self,_windows_.new_PopupWindow(*args,
**kwargs))
NotImplementedError

And thinking about it, it's so bizarrely wrong even if it does work!
Having menu bars appear on a mac, that is. If this was added I'd almost
certainly use it in our application-- but use a thin wrapper around it, such
that on a mac it just totally bypasses all of FlatMenu and creates a
standard menubar for the window, but on the PC it makes a FlatMenu. I don't
know how closely you're following the menubar API so how easy that'd be, but
IMHO that's how I'd use it on a mac

Yes, Tim pointed me to the fact that wx.PopupWindow still doesn't work
on Mac. But (in theory), this should change in the next release, as
far as I know, in which we will have a wx.PopupWindow also for wxMAC.
It's curious in the end, wx.PopupWindow is such a useful widget, I
thought it should have been implemented also on the Mac platform ages
ago. How do they emulate a wx.PopupWindow in Mac in other apps? It has
to be there, I can't believe Steve Jobs (or whatever is his name)
hasn't thought about it.
Anyway, if and when wx.PopupWindow will be available on wxMAC, I'd
love to hear about bugs and suggestions about FlatMenu from Mac users.
However, everything is subordinate to Robin's decision about the
inclusion of FlatMenu in wx.lib. In any case, FlatMenu will always
live on my website.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 9/29/07, Stephen Hansen wrote:

Alexei_Vinidiktov · September 30, 2007, 1:09am

Andrea Gavana пишет:

Hi All,

I have been working for a while to update and check FlatMenu for a
(possible) inclusion of this module inside wx.lib for the next
release, depending on Robin's opinion.
With the kind suggestions from Tim Morton, who reported bugs and
limitations of FlatMenu, I think I have almost kicked out all the
issues.
However, one problem still remains, and it is related to a difference
between LCD and CRT monitors. I have an LCD monitor at home and a CRT
at work, so I could verify the issue. In Tim's words:

"However, I have found another peculiar problem with the Flatmenu
display on LCD monitors. I normally use a Viewsonic 19in CRT monitor
and the display of the menu when it is activated with a mouseover is
fine, but when I view it on (two different) LCD monitors the menu text
becomes rough, jagged and somewhat bold. It remains when the mouse
leaves. The whole app must be resized horizontally to refresh it back
to normal appearence."

I attach the screenshots Tim sent to me to demonstrate the problem. I
have absolutely no idea why the 2 kind of monitors should behave
differently in this case, but I though that someone more knowledgeable
than me might shed some light on this problem.

I'm getting the same result here on an LCD monitor.

And I also seem to have stumbled across a bug. Menu scrolling for the long menu in the demo doesn't work for me. When I click the down arrow nothing happens.

Otherwise great work, Andrea!

I'm on WinXP Pro SP2, Python 2.5, wxPython 2.8.6.0.

···

--
Alexei Vinidiktov

Andrea_Gavana · September 30, 2007, 9:36am

Hi Alexei,

···

On 9/30/07, Alexei Vinidiktov <alexei.vinidiktov@gmail.com> wrote:

Andrea Gavana пишет:
> Hi All,
>
> I have been working for a while to update and check FlatMenu for a
> (possible) inclusion of this module inside wx.lib for the next
> release, depending on Robin's opinion.
> With the kind suggestions from Tim Morton, who reported bugs and
> limitations of FlatMenu, I think I have almost kicked out all the
> issues.
> However, one problem still remains, and it is related to a difference
> between LCD and CRT monitors. I have an LCD monitor at home and a CRT
> at work, so I could verify the issue. In Tim's words:
>
> "However, I have found another peculiar problem with the Flatmenu
> display on LCD monitors. I normally use a Viewsonic 19in CRT monitor
> and the display of the menu when it is activated with a mouseover is
> fine, but when I view it on (two different) LCD monitors the menu text
> becomes rough, jagged and somewhat bold. It remains when the mouse
> leaves. The whole app must be resized horizontally to refresh it back
> to normal appearence."
>
> I attach the screenshots Tim sent to me to demonstrate the problem. I
> have absolutely no idea why the 2 kind of monitors should behave
> differently in this case, but I though that someone more knowledgeable
> than me might shed some light on this problem.
>

I'm getting the same result here on an LCD monitor.

And I also seem to have stumbled across a bug. Menu scrolling for the
long menu in the demo doesn't work for me. When I click the down arrow
nothing happens.

It's not a bug, is a missing feature . At the beginning of the
documentation and in FlatMenu web page, I have specified that menu
scrolling has not been implemented yet.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Alexei_Vinidiktov · September 30, 2007, 10:01am

Andrea Gavana wrote:

Hi Alexei,

[...]

And I also seem to have stumbled across a bug. Menu scrolling for the
long menu in the demo doesn't work for me. When I click the down arrow
nothing happens.

It's not a bug, is a missing feature . At the beginning of the
documentation and in FlatMenu web page, I have specified that menu
scrolling has not been implemented yet.

Andrea.

Sorry, I somehow missed it.

···

--
Alexei Vinidiktov

Chris_Mellon · October 1, 2007, 3:12pm

This looks like what happens when you re-draw anti-aliased text over
itself without erasing first. You probably have cleartype (which
anti-aliases text) turned on on your LCD, and not on your CRT (where
it tends to look terrible), which is why the bug correlates with your
monitor type.

Try using a solid background mode when you draw your text instead of a
transparent brush.

···

On 9/29/07, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi All,

I have been working for a while to update and check FlatMenu for a
(possible) inclusion of this module inside wx.lib for the next
release, depending on Robin's opinion.
With the kind suggestions from Tim Morton, who reported bugs and
limitations of FlatMenu, I think I have almost kicked out all the
issues.
However, one problem still remains, and it is related to a difference
between LCD and CRT monitors. I have an LCD monitor at home and a CRT
at work, so I could verify the issue. In Tim's words:

"However, I have found another peculiar problem with the Flatmenu
display on LCD monitors. I normally use a Viewsonic 19in CRT monitor
and the display of the menu when it is activated with a mouseover is
fine, but when I view it on (two different) LCD monitors the menu text
becomes rough, jagged and somewhat bold. It remains when the mouse
leaves. The whole app must be resized horizontally to refresh it back
to normal appearence."

I attach the screenshots Tim sent to me to demonstrate the problem. I
have absolutely no idea why the 2 kind of monitors should behave
differently in this case, but I though that someone more knowledgeable
than me might shed some light on this problem.

Moreover, I still have no idea on the behavior of FlatMenu on Mac, so
if there is one (or more) kind soul who will try it on a Mac and
report back problems and issues, I will be glad to address them. For
all users, the latest FlatMenu release can be found in the usual
place:

http://xoomer.alice.it/infinity77/main/freeware.html#flatmenu

Thank you for your suggestions.

Andrea_Gavana · October 1, 2007, 3:33pm

Hi Chris,

···

On 10/1/07, Chris Mellon wrote:

This looks like what happens when you re-draw anti-aliased text over
itself without erasing first. You probably have cleartype (which
anti-aliases text) turned on on your LCD, and not on your CRT (where
it tends to look terrible), which is why the bug correlates with your
monitor type.

Try using a solid background mode when you draw your text instead of a
transparent brush.

Thank you for your suggestion. However, FlatMenu has a gradient
background (in the menu bar), so I suppose that using a solid
background for the text might screw up this "nice-looking" effect...

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Chris_Mellon · October 1, 2007, 4:01pm

Erase and accept the flicker or double buffering are your only options, then...

I'm not sure which versions of wxPython you're supporting, but you
could also try using wxGC and draw the whole area at once, using a
gradient brush.

···

On 10/1/07, Andrea Gavana <andrea.gavana@gmail.com> wrote:

Hi Chris,

On 10/1/07, Chris Mellon wrote:
> This looks like what happens when you re-draw anti-aliased text over
> itself without erasing first. You probably have cleartype (which
> anti-aliases text) turned on on your LCD, and not on your CRT (where
> it tends to look terrible), which is why the bug correlates with your
> monitor type.
>
> Try using a solid background mode when you draw your text instead of a
> transparent brush.

Thank you for your suggestion. However, FlatMenu has a gradient
background (in the menu bar), so I suppose that using a solid
background for the text might screw up this "nice-looking" effect...

Andrea.

Robin · October 1, 2007, 7:57pm

Chris Mellon wrote:

This looks like what happens when you re-draw anti-aliased text over
itself without erasing first. You probably have cleartype (which
anti-aliases text) turned on on your LCD, and not on your CRT (where
it tends to look terrible), which is why the bug correlates with your
monitor type.

That's my guess too. In a nutshell what is happening is that when the text is redrawn the anti-aliased portion of the new text is being blended with the background pixels that are already there, (the anti-aliased pixels from the previous draw) and are ending up darker than if they had been blended with the real background pixels. The more you draw the text, the darker the blended pixels will become until they are full black and make the text look distorted and blocky.

Try using a solid background mode when you draw your text instead of a
transparent brush.

Or simply ensure that the text is only drawn once each time the background behind it is drawn.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Alexei_Vinidiktov · November 1, 2007, 4:17pm

Andrea Gavana пишет:

AttributeError: 'unicode' object has no attribute '_title'

That's a bug in FlatMenu: on line 266, try to replace the following line:

if type(titleOrMenu) == type(""):

With this line:

if isinstance(titleOrMenu, basestring):

And it should work... I didn't test it, as I don't have the unicode
version here, but please let me know if you encounter any problem.

Now unicode strings seem to work, but not completely.

Using wx.SYS_DEFAULT_GUI_FONT, as it seems, instructs Windows to use the MS Sans Serif font which is not Unicode, and thus the unicode characters which are not part of the system default code page (in my case Cyrillic and Latin) are not displayed correctly in the menu.

If I change wx.SYS_DEFAULT_GUI_FONT back to wx.SYS_DEFAULT_GUI_FONT, all the characters are displayed correctly, but then again appears the font rendering issue. By the way, when the form appears there is no rendering issue, but I begin to see it when I hover my mouse over the menu bar.

I'm on Windows XP Pro SP2, wxPython 2.8.6.1, Python 2.5.1.

···

--
Alexei Vinidiktov

Andrea_Gavana · November 2, 2007, 12:27am

Hi Robin,

···

On 11/2/07, Robin Dunn wrote:

Andrea Gavana wrote:

> Curiously, just replacing this line:
>
> fnt = wx.SystemSettings_GetFont(wx.SYS_DEFAULT_GUI_FONT)
>
> with this line:
>
> fnt = wx.SystemSettings_GetFont(wx.SYS_ANSI_VAR_FONT)
>
> Fixed the issue. I have no idea why, but it works.

Probably because the font used in that case on your system is either a
bitmap font (instead of a vector format like TTF) or doesn't specify any
hinting that the system will use for anti-aliased drawing.

I expect that the only way to truly solve this for any font is to make
sure that the text only gets drawn once. If it needs to be drawn again
for some reason, such as it is part of the update region in a paint
event, then you either need to redraw everything 'behind' it too, or
don't use dc.SetBackgroundMode(wx.TRANSPARENT). To better see what is
happening you should get a tool that lets you zoom in on the display and
see the individual pixels magnified. If you look at some text then if
it's using anti-aliasing (or 'font smoothing' or 'ClearType') you'll see
some pixels along the curves and corners that are not fully black, or
that may even have some color. If the same text gets redrawn at the
same place then those aliased pixels will be blended with the ones that
are already there and they will become a little bit darker, and a little
more dark the next time it is drawn.

I guess the only thing I have to do is what you said... let's hope I
will be able to find out why is painting twice the same text

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/