chromium-dev

[Chromium-dev] Patch for windows

[<dr...@bf...>]

Please find attached a patch with some fixes for the OpenGL stub on windows:

1. The functions wglGetCurrentContext() and wglGetCurrentDC() return 
NULL in the current implementation. I changed them to return the proper 
GL context and device context respectively.

2. In wglChoosePixelFormat() okayFlags should include 
PFD_GENERIC_FORMAT. The flag basically says that there is no hardware 
acceleration at all [1], [2].

[1] 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/ntopnglr_73jm.asp
[2] http://www.microsoft.com/msj/archive/S2085.aspx


Michael

Re: [Chromium-dev] Patch for windows

[Brian P. <bri...@tu...>]

Michael D=FCrig wrote:
>=20
> Please find attached a patch with some fixes for the OpenGL stub on=20
> windows:
>=20
> 1. The functions wglGetCurrentContext() and wglGetCurrentDC() return=20
> NULL in the current implementation. I changed them to return the proper=
=20
> GL context and device context respectively.
>=20
> 2. In wglChoosePixelFormat() okayFlags should include=20
> PFD_GENERIC_FORMAT. The flag basically says that there is no hardware=20
> acceleration at all [1], [2].

I'm a little hesitant to make the second change.  Is there a chance=20
any apps will check for that flag and decide they don't want to run?

Chromium isn't a hardware driver and not a full software driver either.

-Brian

Re: [Chromium-dev] Patch for windows

[<dr...@bf...>]

Brian Paul wrote:
> Michael Dürig wrote:
>>
>> 2. In wglChoosePixelFormat() okayFlags should include 
>> PFD_GENERIC_FORMAT. The flag basically says that there is no hardware 
>> acceleration at all [1], [2].
> 
> I'm a little hesitant to make the second change.  Is there a chance any 
> apps will check for that flag and decide they don't want to run?
> 
> Chromium isn't a hardware driver and not a full software driver either.
> 

I had to set this flag in order to get the BS Contact VRML/X3D software 
to work (see http://bitmanagement.de/products/bs_contact_vrml.en.html). 
This software can either run in 'normal mode' or in 'software rendering' 
mode. In normal mode it checks for the flag PFD_GENERIC_ACCELERATED and 
in software rendering mode it checks for the PFD_GENERIC_FORMAT flag. 
Without my patch the software wont run with Chromium.

Maybe a better solution might be to include the PFD_GENERIC_ACCELERATED 
flag instead? According to [2] this flag indicates sort of a hybrid 
driver which might better suit Chromium.

Michael

Re: [Chromium-dev] Patch for windows

[Brian P. <bri...@tu...>]

Michael D=FCrig wrote:
> Brian Paul wrote:
>=20
>>Michael D=FCrig wrote:
>>
>>>2. In wglChoosePixelFormat() okayFlags should include=20
>>>PFD_GENERIC_FORMAT. The flag basically says that there is no hardware=20
>>>acceleration at all [1], [2].
>>
>>I'm a little hesitant to make the second change.  Is there a chance any=
=20
>>apps will check for that flag and decide they don't want to run?
>>
>>Chromium isn't a hardware driver and not a full software driver either.
>>
>=20
>=20
> I had to set this flag in order to get the BS Contact VRML/X3D software=
=20
> to work (see http://bitmanagement.de/products/bs_contact_vrml.en.html).=
=20
> This software can either run in 'normal mode' or in 'software rendering=
'=20
> mode. In normal mode it checks for the flag PFD_GENERIC_ACCELERATED and=
=20
> in software rendering mode it checks for the PFD_GENERIC_FORMAT flag.=20
> Without my patch the software wont run with Chromium.
>=20
> Maybe a better solution might be to include the PFD_GENERIC_ACCELERATED=
=20
> flag instead? According to [2] this flag indicates sort of a hybrid=20
> driver which might better suit Chromium.

I was planning on releasing Cr 1.9 today.  I'd rather not risk a=20
last-minute change, OK?

-Brian

Re: [Chromium-dev] Patch for windows

[<dr...@bf...>]

Brian Paul wrote:
>> Maybe a better solution might be to include the 
>> PFD_GENERIC_ACCELERATED flag instead? According to [2] this flag 
>> indicates sort of a hybrid driver which might better suit Chromium.
> 
> I was planning on releasing Cr 1.9 today.  I'd rather not risk a 
> last-minute change, OK?

No problem. I think the semantics of these flags are not very clear. 
Moreover I think they are not properly used by the BS Contact VRML/X3D 
application either. That is, if neither PFD_GENERIC_FORMAT nor 
PFD_GENERIC_ACCELERATED is set (as it is the case with Chromium) the 
application should not take this as a reason to abort. I will try to 
discuss this matter with the folks at Bitmanagement.

Michael