Hello,
I'm going slightly mad! 
I have an application, actually a bunch of applications where I have a
serious problem with the printing subsystem of wxPython.
Everything seams to work just fine. I send the data to the print but
printer.Print(self, printout, True)
returns only when I close the Frame.
In another application I have to switch some panels to see that small
dialog that says "Printing".
Commenting stuff in my latest app I found a culprit BUT it makes no sense.
data = capt.convert('RGB')
where capt is a PIL image. All this happens in a wx.Timer event that
is updating a bitmap that is being drawn on a wx.Panel.
The PIL is from a VideoDevice.
Does any of you have any idea about what is going on? Any suggestion
on what I might try?
Thank you in advance!
Peter
路路路
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
More data for people who might run into the same issue.
I reduce the frequency with which the timer was being fired and the
problem disappeared.
I would still like to know what the heck happens. 
If anyone has any insights... please share.
Peter
路路路
On Wed, Aug 26, 2009 at 2:45 PM, Peter Damoc<pdamoc@gmail.com> wrote:
Hello,
I'm going slightly mad!
I have an application, actually a bunch of applications where I have a
serious problem with the printing subsystem of wxPython.
Everything seams to work just fine. I send the data to the print but
printer.Print(self, printout, True)
returns only when I close the Frame.
In another application I have to switch some panels to see that small
dialog that says "Printing".
Commenting stuff in my latest app I found a culprit BUT it makes no sense.
data = capt.convert('RGB')
where capt is a PIL image. All this happens in a wx.Timer event that
is updating a bitmap that is being drawn on a wx.Panel.
The PIL is from a VideoDevice.
Does any of you have any idea about what is going on? Any suggestion
on what I might try?
Thank you in advance!
Peter
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
Peter Damoc wrote:
More data for people who might run into the same issue.
I reduce the frequency with which the timer was being fired and the
problem disappeared.
I would still like to know what the heck happens.
take a look at recent threads -- there was one about similar issues -- sorry, I can't remember what the title was. Look for Robin's messages -- he posted a good description of the event processing.
Short version: a timer puts an event on the event stack -- if it takes longer to process that event than the time between timer firings, you can get a lot of events clogging up the stack, which can block other things from happening when you want them to.
-Chris
路路路
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
I suspect that the timer was firing before the image had finished
rendering and released a lock on the buffer so you were ending up with
a deadlock until exit, since the new timer could halt the processing
of the old one while it waits for the lock to be released which can't
happen until the old one finishes processing.... on exit the timer
events queued start getting deleted in reverse order until the locked
out process stops being locked out.
If you need to process as fast as possible you could check a semaphore
on processing start and if it is free set it then perform your
processing and clear it, that way whatever you had started would
finish, even at the cost of some missed frames.
Gadget Steve
路路路
On Aug 26, 6:36 pm, Peter Damoc <pda...@gmail.com> wrote:
More data for people who might run into the same issue.
I reduce the frequency with which the timer was being fired and the
problem disappeared.
I would still like to know what the heck happens.
If anyone has any insights... please share.
Peter
On Wed, Aug 26, 2009 at 2:45 PM, Peter Damoc<pda...@gmail.com> wrote:
> Hello,
> I'm going slightly mad!
> I have an application, actually a bunch of applications where I have a
> serious problem with the printing subsystem of wxPython.
> Everything seams to work just fine. I send the data to the print but
> printer.Print(self, printout, True)
> returns only when I close the Frame.
> In another application I have to switch some panels to see that small
> dialog that says "Printing".
> Commenting stuff in my latest app I found a culprit BUT it makes no sense.
> data = capt.convert('RGB')
> where capt is a PIL image. All this happens in a wx.Timer event that
> is updating a bitmap that is being drawn on a wx.Panel.
> The PIL is from a VideoDevice.
> Does any of you have any idea about what is going on? Any suggestion
> on what I might try?
> Thank you in advance!
> Peter
> --
> There is NO FATE, we are the creators.
> blog:http://damoc.ro/
--
There is NO FATE, we are the creators.
blog:http://damoc.ro/- Hide quoted text -
- Show quoted text -
Hi Chris,
The strange thing is that the timer events "appear" to be discarded.
The applications takes "frames" from a webcam and displays them in real time.
If the timer events would have been clogging up the stack I should
have seen a serious delay between the time I do something in front of
the camera and the time it displays.
Also, the printer part would have executed eventually.... but it never
seams to be executed, and I have waited for it... minutes...
Peter
路路路
On Wed, Aug 26, 2009 at 11:05 PM, Christopher Barker<Chris.Barker@noaa.gov> wrote:
Peter Damoc wrote:
More data for people who might run into the same issue.
I reduce the frequency with which the timer was being fired and the
problem disappeared.
I would still like to know what the heck happens.
take a look at recent threads -- there was one about similar issues --
sorry, I can't remember what the title was. Look for Robin's messages --
he posted a good description of the event processing.
Short version: a timer puts an event on the event stack -- if it takes
longer to process that event than the time between timer firings, you
can get a lot of events clogging up the stack, which can block other
things from happening when you want them to.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
>
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/