[vtkusers] ChoosePixelFormat failed error
David Gobbi
david.gobbi at gmail.com
Wed Feb 16 20:42:20 EST 2011
It was very ad-hoc. But the basic idea is this: wx had to create the window
and call SetWindowId before VTK itself tried to create the window.
But VTK had to be the first to paint the window (i.e. before wx did so).
This was where the real annoyance was, because wx liked to clear the
window to black at odd times (this would also result in an annoying
flickering at times). I suspect that Java is doing something similar, i.e.
it probably paints the window before VTK sometimes. Repaint requests
usually originate within the windowing system (i.e. related to mouse
movements or similar things) which is why the problem would appear
at some times but not others. If something triggers Java to repaint the
window before VTK paints it, you have a problem.
In Qt, the window painting is very predictable so people using Qt/VTK
won't see this problem. I'm sure that if someone looks deeply enough
into Java, they can sort out the issue there, too.
- David
On Wed, Feb 16, 2011 at 6:04 PM, Mark Roden <mmroden at gmail.com> wrote
> I've seen the errors as well, but the fixes appear to be very platform
> dependent (like loading libraries in windows in the right order during
> linking, etc).
>
> When you were doing this in wxPython, what was the correct order, so I
> can go ahead and check for that? Maybe there's a way to force them to
> play nice.
>
> Thanks,
> Mark
>
> On Wed, Feb 16, 2011 at 4:52 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> By the way, I did a quick google search, and people have been
>> asking about this Java/PixelFormat problem for years and years.
>> I didn't look around enough to see if anyone reported a fix.
>>
>> On Wed, Feb 16, 2011 at 5:42 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> Hi Mark,
>>>
>>> I've seen this sort of ChoosePixelFormat issue before, it seems
>>> to occur sometimes when VTK is used together with a GUI toolkit,
>>> and is even more likely when a wrapper-language is involved.
>>>
>>> As far as I understand it, when the VTK render window is
>>> embedded within a GUI window (in your case, the Java
>>> canvas/panel), the GUI sometimes generates a window that has
>>> a pixel format that is incompatible with VTK, and then embeds
>>> a vtkRenderWindow in that window.
>>>
>>> For VTK/wxPython, I remember having to do lots of tweaks in
>>> order to get wx and VTK to play nice with each other. My
>>> debugging technique was to add print statements to the code
>>> on both the GUI side and the VTK side when either one of them
>>> made any calls related to setting up Windows, so that I could
>>> make sure that everything was happening in the correct order.
>>>
>>> It seems like a waste now, since I never really used wx after
>>> that. Anyways, a similar technique could be used to sort out
>>> what VTK/Java might be doing wrong.
>>>
>>> - David
>>>
>>>
>>> On Wed, Feb 16, 2011 at 4:38 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> I have vtk 5.9 (git sync to head) wrapped in java, compiled in vs2008
>>>> release mode. Every three to five times I run my app (three
>>>> imageviewer2 objects, one vtkSmartVolumeMapper to a 3D rendering), I
>>>> get a ChoosePixelFormat error that crashes the program abruptly when
>>>> running on Windows 7 64 bits.
>>>>
>>>> What's going on here? If it's a driver bug, it's persistent across
>>>> three different machines with three different graphics cards (one is a
>>>> homebuilt machine, the other two are laptops). Is there a way to
>>>> debug this? It's becoming a showstopping bug.
>>>>
>>>> Thanks,
>>>> Mark
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>
>>>
>>
>
More information about the vtkusers
mailing list