ResourcePackage has some mechanisms that auto-convert image files into .pngs encoded in files (using img2img.convert). I just upgraded the generated code to use wxPython 2.5 style wx.XXX naming and discovered that, on re-generating the files, the images are either of much lower quality, or cause memory access failures (normally on GetIcon, but not GetBitmap AFAICS). This seems as though it may be a strictness issue (the source PNGs causing the problem have alpha channels that were previously accepted as masks, in at least one case the PNGs are showing up as all-black when converted to wx.Bitmap instances, and attempting to convert them to a wx.Icon is causing the memory-access error). Switching back to old-style naming has no effect.
So, is there a known tightening of what's allowed (I don't see anything in the migration guide) in Icon bitmaps? These same files were working well with the wxPython 2.4 releases (and worked fine with the 2.5 releases with the files generated by wxPython 2.4's img2img), so I'm guessing it has to do with either img2img changing or something getting too strict in 2.5. I'm wondering if possibly 2.5 is not converting the alpha channel to a mask or something similar and wxIcon is now more strict about having an explicitly set mask?
One of the embedded resources that causes the memory error on getIcon() is attached. Init image handlers, then call getIcon() and a memory access failure results. I'm really hoping this isn't one of the "you have to delay all this until after the App is created" deals, (and I assume not, as it was working in 2.5 up until I re-built this module), as these resources really are shared (cross-application) resources that I don't want the user/end-developer to have to manually initialise (or have me do a lot of fragile bookkeeping to track and try to hook into initialisation).
ResourcePackage has some mechanisms that auto-convert image files into .pngs encoded in files (using img2img.convert). I just upgraded the generated code to use wxPython 2.5 style wx.XXX naming and discovered that, on re-generating the files, the images are either of much lower quality, or cause memory access failures (normally on GetIcon, but not GetBitmap AFAICS). This seems as though it may be a strictness issue (the source PNGs causing the problem have alpha channels that were previously accepted as masks, in at least one case the PNGs are showing up as all-black when converted to wx.Bitmap instances, and attempting to convert them to a wx.Icon is causing the memory-access error). Switching back to old-style naming has no effect.
So, is there a known tightening of what's allowed (I don't see anything in the migration guide) in Icon bitmaps? These same files were working well with the wxPython 2.4 releases (and worked fine with the 2.5 releases with the files generated by wxPython 2.4's img2img), so I'm guessing it has to do with either img2img changing or something getting too strict in 2.5. I'm wondering if possibly 2.5 is not converting the alpha channel to a mask or something similar and wxIcon is now more strict about having an explicitly set mask?
Alpha channels in .PNG files are now preserved, so they can be drawn with alpha blending. Not sure what's going on with getIcon though, I'll
check it out.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
One of the embedded resources that causes the memory error on getIcon() is attached. Init image handlers, then call getIcon() and a memory access failure results. I'm really hoping this isn't one of the "you have to delay all this until after the App is created" deals, (and I assume not, as it was working in 2.5 up until I re-built this module),
It is. Icons must have a mask (not alpha) and so if the bitmap does not have one a mask is created for it usign wxLIGHT_GREY when it is converted to a wxIcon. But if it is done before the app object is created then wxLIGHT_GREY has not been initialized yet.
as these resources really are shared (cross-application) resources that I don't want the user/end-developer to have to manually initialise (or have me do a lot of fragile bookkeeping to track and try to hook into initialisation).
Wrapping them in a singleton or similar that initializes upon first use should be possible. It could also raise an exception if wx.GetApp() returns None.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
One of the embedded resources that causes the memory error on getIcon() is attached. Init image handlers, then call getIcon() and a memory access failure results. I'm really hoping this isn't one of the "you have to delay all this until after the App is created" deals, (and I assume not, as it was working in 2.5 up until I re-built this module),
It is. Icons must have a mask (not alpha) and so if the bitmap does not have one a mask is created for it usign wxLIGHT_GREY when it is converted to a wxIcon. But if it is done before the app object is created then wxLIGHT_GREY has not been initialized yet.
Is there a way to convert the alpha to a bitmask? I don't see anything automatic.
Wrapping them in a singleton or similar that initializes upon first use should be possible. It could also raise an exception if wx.GetApp() returns None.
Sigh. Ick. I do so dislike writing bookkeeping code like that. Oh well, yet more to do when I get a chance to work on this stuff again.
Is there a way to convert the alpha to a bitmask? I don't see anything automatic.
There isn't anything automatic there now but it could probably be done with some manipulations of a wx.Image. Get the alpha value for each pixel and if it is above some threshold set the colour of that pixel to the mask colour.
Ick and egads! Sure they're small images, but that just *sounds* evil somehow. I'll hopefully figure out something better than that, after all, up until I rebuilt the image sources with 2.5 they were working fine, so *something* has to be able to do this automatically.
Wrapping them in a singleton or similar that initializes upon first use should be possible. It could also raise an exception if wx.GetApp() returns None.
Sigh. Ick. I do so dislike writing bookkeeping code like that. Oh well, yet more to do when I get a chance to work on this stuff again.
Another alternative is to simply warn your users about the issue and suggest that they delay importing the modules containing the resources until after the app object has been created or in the App's OnInit.
I just *will not* do that to my users . It means they have to do all sorts of contortions in their code just to be sure they don't do something completely natural in Python programming. I'll figure something out .
. It means they have to do all sorts of contortions in their code just to be sure they don't do something completely natural in Python programming. I'll figure something out