Google Sketch-Up Not Starting

[Vijay Kiran Kamuju]

Hi,

I tried to start latest tool form the Google Stable, Google SketchUp.
This is a product Google acquired by the acquisition of @land Software.
Now this tool is giving a Dialog box about incorrect display drivers and
saying that ChoosePixelFormat Failed.

Now what should i try more (debug channels)

no err msgs are shown in the cmd prompt.

Thanks,
Vijay

[Mike Hearn]

Funny, I was looking at this today. It does something odd with the
flags, we're not passing back what it expects. In some cases it seems to
expect SWAP_COPY to be set, but I added that in and saw no difference, so
still a bit of remaining work. 

But basically despite the error it's calling DescribePixelFormat not
ChoosePixelFormat. We need to find out why it's not happy with the results
from that function and fix it.

[Andreas Mohr]

Hi,

On Fri, Apr 28, 2006 at 09:28:10PM +0100, Mike Hearn wrote:
> Funny, I was looking at this today. It does something odd with the
> flags, we're not passing back what it expects. In some cases it seems to
> expect SWAP_COPY to be set, but I added that in and saw no difference, so
> still a bit of remaining work.
>
> But basically despite the error it's calling DescribePixelFormat not
> ChoosePixelFormat. We need to find out why it's not happy with the results
> from that function and fix it.

Hmm... ordinal mixup issue?
Probably it's the error message which is wrong, but possibly it's our
ChoosePixelFormat which sits at the wrong place...

Andreas

-- 
No programming skills!? Why not help translate many Linux applications! 
https://launchpad.ubuntu.com/rosetta
(or alternatively buy nicely packaged Linux distros/OSS software to help
support Linux developers creating shiny new things for you?)

[Mike Hearn]

On 5/1/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:
> Hmm... ordinal mixup issue?
> Probably it's the error message which is wrong, but possibly it's our
> ChoosePixelFormat which sits at the wrong place...

I don't think so. It happily loops around calling DescribePixelFormat
looking for a matching descriptor, it just never finds one it's
satisfied with ...

[Huw Davies]

On Mon, May 01, 2006 at 12:09:18PM +0100, Mike Hearn wrote:
> On 5/1/06, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:
> > Hmm... ordinal mixup issue?
> > Probably it's the error message which is wrong, but possibly it's our
> > ChoosePixelFormat which sits at the wrong place...
>
> I don't think so. It happily loops around calling DescribePixelFormat
> looking for a matching descriptor, it just never finds one it's
> satisfied with ...

Yeah, I think the problem is the flags we return.  Adding
PFD_GENERIC_FORMAT if we don't set PFD_GENERIC_ACCELERATED helps.  But
then we run into the opengl in a child window bug...

Huw.

[Mike Hearn]

> Yeah, I think the problem is the flags we return.  Adding
> PFD_GENERIC_FORMAT if we don't set PFD_GENERIC_ACCELERATED helps.  But
> then we run into the opengl in a child window bug...

Somebody suggested a way to fix this using pbuffers or something like
that a while ago - apparently it would take a performance hit but
still work without X extensions. Is that idea still feasable?

[Lionel Ulmer]

On Mon, May 01, 2006 at 12:19:47PM +0100, Huw Davies wrote:
> Yeah, I think the problem is the flags we return.  Adding
> PFD_GENERIC_FORMAT if we don't set PFD_GENERIC_ACCELERATED helps.  But
> then we run into the opengl in a child window bug...

Yes, this 'patch' helps it to start:

Index: dlls/x11drv/opengl.c
===================================================================
RCS file: /home/wine/wine/dlls/x11drv/opengl.c,v
retrieving revision 1.26
diff -u -r1.26 opengl.c
--- dlls/x11drv/opengl.c        27 Mar 2006 11:30:29 -0000      1.26
+++ dlls/x11drv/opengl.c        1 May 2006 12:11:14 -0000
@@ -384,7 +384,7 @@
   ppfd->nVersion = 1;
 
   /* These flags are always the same... */
-  ppfd->dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL;
+  ppfd->dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_GENERIC_FORMAT;
   /* Now the flags extracted from the Visual */
 
   wine_tsx11_lock();


I looked at the 'code' (ahem :-) ) and it seems that it checks either for
'PFD_GENERIC_FORMAT' / 'PFD_GENERIC_ACCELERATED' flags depending on some
internal arguments. It loops multiple times on the pixel formats but the
only one it seems to like are the one that are supposedly reported by the
un-accelerated reference driver (so if you installed an ICD you are out of
luck). I did not find out though why it does not like our accelerated ones
though.

Note that it does not start either on my WinXP Pro laptop so well, I guess
this is an application which is VERY picky on the pixel formats it likes and
I hope it will be fixed in a forthcoming patch to the application :-)

A 'work-around' for Wine would be report twice the number of visuals, one set
'generic' and the other 'accelerated' (but well, as some applications like
SeriousSam check for these bits too, no idea if they would like it).

         Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/