chromium-dev — For developers of the Chromium framework or SPU's

[Chromium-dev] About frame rate of Chromium

[wangshuai <ws...@ho...>]

Q2hyb21pdW0tdXNlcnOjrEhlbGxlb6OhDQoJCQ0KCUkgYW0gYSBuZXcgdXNlciBvZiBDaHJvbWl1
bS4NCglBbmQgSSBidWlsZCBhIGNsdXN0ZXIgd2l0aCAzIG5vZGUob25lIGlzIGNsaWVudCxvdGhl
cnMgYXJlIHNlcnZlcnMpIGFuZCAxMDBNIEV0aGVybmV0LiANCgkNCglJIHJ1biAiY2l0eSIgd2l0
aG91dCBDaHJvbWl1bSBhbmQgdGhlIGZyYW1lIHJhdGUgaXMgODAuDQoJSG93ZXJ2ZXIsd2hlbiBJ
IHJ1biAiY2l0eSIgb24gQ2hyb21pdW0gd2l0aCAic2ltcGxlbXVyYWwuY29uZiIsIHRoZSBmcmFt
ZSByYXRlIGlzIG9ubHkgNTAuDQoJDQoJQ2FuIGFueW9uZSB0ZWxsIG1lIHNvbWUgdGVzdCByZXN1
bHRzIGFib3V0IHlvdXJzPw0KICAJDQoNCqGhoaGhoaGhoaGhoaGhoaF3YW5nc2h1YWkNCqGhoaGh
oaGhoaGhoaGhoaF3c18yMDAyQGhvdG1haWwuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDQt
MDYtMjUNCg==

Re: [Chromium-dev] Re: [Chromium-users] Fedora Core 2 (Xorg) issues

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

Mike Houston wrote:
> 
>> [...]
>>
>> This is funny.  Notice that glXMakeCurrent is being called with two 
>> different windows (8388610 and 8388612), and two different contexts.
>>
>> Are you using the same version of GLUT that you've always been using? 
>>  I wonder if FC2 is using "freeglut" instead of the Kilgard library.
>>
>> -Brian
>>
> Say NO to FreeGLUT!  Everything is working again with RH9's glut 
> package.  What the heck is wrong with how freeglut works?...  grumble, 
> grumble.
> Can one of the RedHat folks take a look at freeglut, since it now ships 
> with Fedora, and see what the heck is breaking Chromium?  Outside of 
> Chromium, glut apps seem to work fine with freeglut...

I've got patches for freeglut and Chromium that seem to fix this 
problem.  As I mentioned before, freeglut uses OpenGL to render its 
pop-up menus instead of Xlib or Win32 like the original glut.  The 
second Cr window that's appearing corresponds to the app's glut menu.

The patch to freeglut sets the menu window's name to "freeglut menu" 
and moves the initial call to glXMakeCurrent after the window's name 
is set.

The patch to Chromium adds a new crfaker option 
'ignore_freeglut_menus' (defaults to True) that checks if the window 
title is 'freeglut menu" and causes Chromium to render such windows 
with the native OpenGL.

I'll check in the changes to Chromium and send the patch to the 
freeglut developers.

-Brian

[Chromium-dev] Re: Threading tilesort

[Alan M. <al...@re...>]

On Fri, 2004-06-25 at 13:59, Mike Houston wrote:
> <snip>
> 
> > 
> >>This was one of the reasons I've been pushing for a threaded tilesortSPU 
> >>and a threaded/non-blocking network layer.  The later should just about 
> >>double current SDP performance.  Alas, this is a non-trivial thing to do 
> >>and will cause large changes to the core of Chromium.
> >>
> > 
> > What sort of scheme do you have in mind for tilesort ?
> 
> Tilesort is going to be really tricky to thread, which is why I said 
> it's non-trivial.  It's amazing how fast we become CPU limited with the 
> current tilesort code, even on GigE networks.  Higher speed networks 
> just exacerbate the problem.
> 
> Some of it can probably be optimized (faster frustum/bounding box 
> checking, crPackCanHoldOpcode, etc), but better overlapping with the 
> network layer and app will probably help.  For example, can we give 
> control back to the application after a swap buffers faster by handling 
> the application calls in one thread and the packing and network calls in 
> another?  Can we thread the bounding box/frustum checks for each 
> display?  Can we run the state tracker in a thread which handles updates 
> and queries? etc.
> 
Hmm. Most of my profiling results indicate that the majority of the time
in the tilesorter is spent in the state tracking code.
 crStateCurrentRecover is a major bottleneck. The texture state tracking
code is another one as well since it always seems to be iterating over
maxTextureUnits over and over again. 

Having a threaded non-blocking network layer would help but without any
real hard numbers to go by it's difficult to say how much faster we
could go (now I'm starting to sound like a carpenter .. "measure twice
.. cut once"  :) ).

> Most people have dual processor systems and folks are starting to build 
> quad boxes, so why not try to better use all of the compute resources. 
> Obviously the best performance will come from a distributed application 
> running tilesort in an n to m configuration, but most of the "big" apps 
> are not setup for that just yet.
> 
> -Mike
-- 
Alan Matsuoka
Global Professional Services
Red Hat Canada, Ltd
mailto:al...@re...

[Chromium-dev] Threading tilesort

[Mike H. <mho...@gr...>]

<snip>

> 
>>This was one of the reasons I've been pushing for a threaded tilesortSPU 
>>and a threaded/non-blocking network layer.  The later should just about 
>>double current SDP performance.  Alas, this is a non-trivial thing to do 
>>and will cause large changes to the core of Chromium.
>>
> 
> What sort of scheme do you have in mind for tilesort ?

Tilesort is going to be really tricky to thread, which is why I said 
it's non-trivial.  It's amazing how fast we become CPU limited with the 
current tilesort code, even on GigE networks.  Higher speed networks 
just exacerbate the problem.

Some of it can probably be optimized (faster frustum/bounding box 
checking, crPackCanHoldOpcode, etc), but better overlapping with the 
network layer and app will probably help.  For example, can we give 
control back to the application after a swap buffers faster by handling 
the application calls in one thread and the packing and network calls in 
another?  Can we thread the bounding box/frustum checks for each 
display?  Can we run the state tracker in a thread which handles updates 
and queries? etc.

Most people have dual processor systems and folks are starting to build 
quad boxes, so why not try to better use all of the compute resources. 
Obviously the best performance will come from a distributed application 
running tilesort in an n to m configuration, but most of the "big" apps 
are not setup for that just yet.

-Mike

Re: [Chromium-dev] Darwin Port

[Christopher W. <cr...@ms...>]

Although I used those emails as reference for what I did, I never 
received a copy of the patch.  Do you think you could send that?  It'd 
be much appreciated :)

  -Chris

On Jun 25, 2004, at 5:07 AM, Jorge Luis Williams wrote:

> Did anyone take a look at the patch I submit last December?  It 
> addressed/fixed a lot of these linker problems and got things working 
> for GLX applications on OS X.  I was planning on working on it further 
> this summer but been kinda busy.
>
> -jOrGe W.

Re: [Chromium-dev] Darwin Port

[Jorge L. W. <jo...@jl...>]

Did anyone take a look at the patch I submit last December?  It 
addressed/fixed a lot of these linker problems and got things working 
for GLX applications on OS X.  I was planning on working on it further 
this summer but been kinda busy.

-jOrGe W.

On Jun 24, 2004, at 12:09 PM, Christopher Waters wrote:

> I did some browsing around the Mac documentation, and I came across 
> some articles on Umbrella Frameworks, which is another way of saying 
> "frameworks within frameworks." The nifty thing about these is that 
> when the dynamic linker cannot find a symbol in the base framework, it 
> looks in its child frameworks for the symbols.  This takes care of a 
> lot of problems the dynamic linker has given me about certain symbols 
> it expected to find in libGL.dylib (specifically gll_noop and 
> gll_pkey).  In order to implement this, though, we have to create a 
> temporary framework file structure.  The following is a list of the 
> folders I used to test this out:
>
> /private/tmp/OpenGL.framework
> cwaters% ls -lR
>  Frameworks -> Versions/Current/Frameworks
>  Headers -> Versions/Current/Headers
>  Libraries -> Versions/Current/Libraries
>  OpenGL -> Versions/Current/OpenGL
>  Resources -> Versions/Current/Resources
>  Versions
>
> ./Versions:
>  A
>  Current -> A
>
> ./Versions/A:
>  Frameworks
>  Headers -> 
> /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers
>  Libraries
>  OpenGL -> /cr/lib/Darwin/libcrfaker.dylib
>  Resources -> 
> /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources
>
> ./Versions/A/Frameworks:
>  NOpenGL.framework -> /System/Library/Frameworks/OpenGL.framework
>
> ./Versions/A/Libraries:
>  libGL.dylib -> /cr/lib/Darwin/libcrfaker.dylib
>
> After I made all the folders and symbolic links, I preappeneded "/tmp" 
> to DYLD_FRAMEWORK_PATH (in app_faker.c)
> I wouldn't say it worked sucessfully, since the program itself crashed 
> after creating/setting the context, but I would say that it -worked-, 
> in the sense that the faker's CGL functions were actually called.
>
> Attached is a diff between the HEAD app_faker.c and the app_faker.c 
> with the implementation I wrote for this purpose.
>
>  -Chris Waters
>
> <app_faker.diff>
>
> On Jun 23, 2004, at 2:11 PM, Christopher Waters wrote:
>
>> Attached is the "change log" I made.  The tarballed code can be found 
>> at: http://www.cse.msstate.edu/~crw7/vis/cr-1.1.tar.gz
>> I restarted off of HEAD yesterday morning, so it should be up to date.
>>
>> I got most of my ideas for all of this (using AGL in spus and CGL in 
>> faker; defining SPU before including arch.mk; etc) from Jorge's 
>> "Darwin Patch" mails.
>> Everything builds fine, but then goes downhill when trying to run the 
>> app faker :(
>>
>> There seems to be some trick in "tricking" the dynamic linker, too... 
>> forcing a flat namspace and then inserting the faker library only 
>> worked until you tried to call functions in the actual opengl 
>> library.
>>
>>  -Chris Waters
>>
>> <Darwin_work.rtf>

Re: [Chromium-dev] Darwin Port

[Christopher W. <cr...@ms...>]

I did some browsing around the Mac documentation, and I came across 
some articles on Umbrella Frameworks, which is another way of saying 
"frameworks within frameworks." The nifty thing about these is that 
when the dynamic linker cannot find a symbol in the base framework, it 
looks in its child frameworks for the symbols.  This takes care of a 
lot of problems the dynamic linker has given me about certain symbols 
it expected to find in libGL.dylib (specifically gll_noop and 
gll_pkey).  In order to implement this, though, we have to create a 
temporary framework file structure.  The following is a list of the 
folders I used to test this out:

/private/tmp/OpenGL.framework
cwaters% ls -lR
  Frameworks -> Versions/Current/Frameworks
  Headers -> Versions/Current/Headers
  Libraries -> Versions/Current/Libraries
  OpenGL -> Versions/Current/OpenGL
  Resources -> Versions/Current/Resources
  Versions

./Versions:
  A
  Current -> A

./Versions/A:
  Frameworks
  Headers -> 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers
  Libraries
  OpenGL -> /cr/lib/Darwin/libcrfaker.dylib
  Resources -> 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Resources

./Versions/A/Frameworks:
  NOpenGL.framework -> /System/Library/Frameworks/OpenGL.framework

./Versions/A/Libraries:
  libGL.dylib -> /cr/lib/Darwin/libcrfaker.dylib

After I made all the folders and symbolic links, I preappeneded "/tmp" 
to DYLD_FRAMEWORK_PATH (in app_faker.c)
I wouldn't say it worked sucessfully, since the program itself crashed 
after creating/setting the context, but I would say that it -worked-, 
in the sense that the faker's CGL functions were actually called.

Attached is a diff between the HEAD app_faker.c and the app_faker.c 
with the implementation I wrote for this purpose.

  -Chris Waters

Re: [Chromium-dev] crfaker fix

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

Ok, I think I've fixed this problem.

I moved the declaration of the glim SPUDispatchTable into the 
NULLfuncs.c file where it can be initialized to point to the 
NULL/no-op functions.

So, calling a GL function before a rendering context is created/bound 
should no longer cause a segfault or anything.

-Brian

Greg Humphreys wrote:
> I agree with Brian -- the call to Viewport is meaningless since it is
> not bound to a context yet.
> 
> However, it's quite conceivable that code like this (that calls OpenGL
> before creating / making current to a context) behaves in a very bad
> way on Chromium (e.g., crashing instead of just doing nothing).
> 
> The "right" thing to do, it seems, is to have the faker have a set of
> "nop" functions that everything is bound to before any SPU has been
> loaded.
> 
> 
> ----- Original Message -----
> From: Ricky Uy <ric...@ya...>
> Date: Wed, 23 Jun 2004 11:51:57 -0700 (PDT)
> Subject: Re: [Chromium-dev] crfaker fix
> To: Ricky Uy <ric...@ya...>, Brian Paul <bri...@tu...>
> Cc: chr...@li...
> 
> 
> 
> 
> OK, below is the output from the printspu of a working celestia in
> windows. As can be seen, glViewport is the very first call ever made.
> Putting a call to stubInit() before the jmp in the cr_glViewport in
> windows_exports.c seems to have worked, but I don't feel very good
> about leaving it there. I'm not sure how to resolve this issue, but I
> thought it should be known. There's a couple more apps that do the
> window setup a little sloppy like this, too, and this seems to fix
> those errors, too. I wonder, is glViewport the only gl command that an
> app would ever try to execute before calling any of the wgl
> commands...because then it might be ok to leave the stubInit call
> where it is...
> 
> Ricky
> 
> Viewport( 0, 0, 551, 411 )
> 
> CreateContext( 0012F9E4, 53 )
> 
> = 3000
> 
> CreateContext( 02A51C58, 53 )
> 
> = 3001
> 
> WindowCreate( 02A52100, 53 )
> 
> = 1
> 
> MakeCurrent( 1, -553578510, 3001 )
> 
> Viewport( 0, 0, 551, 411 )
> 
> Viewport( 0, 0, 551, 392 )
> 
> GetString( GL_EXTENSIONS )
> 
> GetIntegerv( GL_MAX_TEXTURE_UNITS, 0x011CD390 )
> 
> GenProgramsARB( 1, 00564928 )
> 
> GetError( )
> 
> 
> 
> Ricky Uy <ric...@ya...> wrote: 
> I tried putting the stubInit() in all the WGL calls like you
> suggested, but it doesn't resolve the issue. I also have all the wgl
> intercepted calls printing out to a file, and it appears that celestia
> is not calling any wgl functions before it calls ShowWindow() (and
> thus glViewport). Perhaps the celestia code is done a little sloppy
> with the window setup (like the way it calls choosepixelformat AFTER
> showwindow), but chromium _should_ still be able to handle this
> properly.
>  Ricky
> 
> Brian Paul <bri...@tu...> wrote:
> 
> There must be _some_ WGL function being called before glViewport. At 
> least wglMakeCurrent() must be called to bind a rendering context. 
> Otherwise, the glViewport call is invalid.
> 
> We can call stubInit() from all the wgl/glx functions in the faker. 
> It returns immediately if it's been called before.
> 
> -Brian
> 
> 
> Ricky Uy wrote:
> 
>>You're right, I found the article you mentioned on MSDN. But if that is 
>>the case, then are applications like Celestia doomed to be able to work 
>>on Chromium in their original, unmodified state? In it's unmodified 
>>state, stubInit() is never going to be called before the glViewport() 
>>call, and I don't see any other areas of the crfaker dll where the call 
>>to stubInit() would make sense. Celestia will just call glViewport and 
>>it will immediately get intercepted by windows_exports.c and try to jmp 
>>to an invalid location. I suppose checks could be made in the 
>>windows_exports file to see if stubInit has already been called or not, 
>>but it wouldn't be good to make function calls like that inside of NAKED 
>>functions. Do you know any other places that might be okay for it?
>>
>>*/Greg Humphreys /* wrote:
>>
>>If I recall correctly, this is (was?) explicitly documented in MSDN as
>>being illegal (manual loading of other DLL's within DLLMain). It USED
>>to be there, and then I discovered this, and moved it.
>>
>>--
>>Greg Humphreys, Assistant Professor
>>Department of Computer Science, University of Virginia
>>http://www.cs.virginia.edu/~humper/
>>
>>
>>On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:
>>
>>
>>>Hi,
>>>
>>>For the Windows version of this library, there should be a call to
>>>stubInit() just before the return in DLLMain() in load.c, and all
>>
>>the
>>
>>>calls to stubInit() should be removed from the wgl functions in
>>
>>wgl.c.
>>
>>>There were several applications that would bail out because of this,
>>>including Celestia for Windows. However with this patch, they all
>>>work.
>>>
>>>The problem was that some applications d on't call wgl functions
>>
>>before
>>
>>>trying to do other things. For example, especially in direct
>>
>>response
>>
>>>to Alicia's post, Celestia would try to call ShowWindow() before
>>>calling ChoosePixelFormat(). This caused a crash because ShowWindow
>>>makes a call to glViewport, and because stubInit() had not yet been
>>>called, the glim dispatch table was nulled out. So there was a
>>
>>crash.
>>
>>>By having stubInit() in DLLMain, issues like these are resolved.
>>>
>>>Now there was a comment above DLLMain saying that Windows didn't
>>
>>allow
>>
>>>the loading of other libraries in DLLMain, and I'm not sure what has
>>>happened since, but it works fine. Hope this helps some people with
>>>their applications.
>>>
>>>Ricky

Re: [Chromium-dev] some per Vertex Commands dont have the pervertex props

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

Keith Whitwell wrote:
> chr...@tm... wrote:
> 
>> Hallo
>> I'm wondering why some commands like glMaterial and glColorMaterial 
>> witch I can use per Vertex, don't have a pervertex attribute in the 
>> props fields in the file APIspec.txt. Is there a reason?
> 
> 
> I can't answer your question, but will point out that while glMaterial 
> is allowed between begin/end, glColorMaterial is not.

Tobias,

Yes, it looks like the glMaterial commands should be tagged as 
'pervertex'.  I'm making the change now.

'pervertex' is only significant in one place at this time: in packer/
pack_header.py

-Brian

Re: [Chromium-dev] Darwin Port

[Christopher W. <cr...@ms...>]

Attached is the "change log" I made.  The tarballed code can be found 
at: http://www.cse.msstate.edu/~crw7/vis/cr-1.1.tar.gz
I restarted off of HEAD yesterday morning, so it should be up to date.

I got most of my ideas for all of this (using AGL in spus and CGL in 
faker; defining SPU before including arch.mk; etc) from Jorge's "Darwin 
Patch" mails.
Everything builds fine, but then goes downhill when trying to run the 
app faker :(

There seems to be some trick in "tricking" the dynamic linker, too... 
forcing a flat namspace and then inserting the faker library only 
worked until you tried to call functions in the actual opengl library.

  -Chris Waters

Re: [Chromium-dev] crfaker fix

[Ricky Uy <ric...@ya...>]

OK, below is the output from the printspu of a working celestia in windows. As can be seen, glViewport is the very first call ever made. Putting a call to stubInit() before the jmp in the cr_glViewport in windows_exports.c seems to have worked, but I don't feel very good about leaving it there. I'm not sure how to resolve this issue, but I thought it should be known. There's a couple more apps that do the window setup a little sloppy like this, too, and this seems to fix those errors, too. I wonder, is glViewport the only gl command that an app would ever try to execute before calling any of the wgl commands...because then it might be ok to leave the stubInit call where it is...

Ricky

Viewport( 0, 0, 551, 411 )

CreateContext( 0012F9E4, 53 )

= 3000

CreateContext( 02A51C58, 53 )

= 3001

WindowCreate( 02A52100, 53 )

= 1

MakeCurrent( 1, -553578510, 3001 )

Viewport( 0, 0, 551, 411 )

Viewport( 0, 0, 551, 392 )

GetString( GL_EXTENSIONS )

GetIntegerv( GL_MAX_TEXTURE_UNITS, 0x011CD390 )

GenProgramsARB( 1, 00564928 )

GetError( )


Ricky Uy <ric...@ya...> wrote:I tried putting the stubInit() in all the WGL calls like you suggested, but it doesn't resolve the issue. I also have all the wgl intercepted calls printing out to a file, and it appears that celestia is not calling any wgl functions before it calls ShowWindow() (and thus glViewport). Perhaps the celestia code is done a little sloppy with the window setup (like the way it calls choosepixelformat AFTER showwindow), but chromium _should_ still be able to handle this properly.
 
Ricky

Brian Paul <bri...@tu...> wrote:

There must be _some_ WGL function being called before glViewport. At 
least wglMakeCurrent() must be called to bind a rendering context. 
Otherwise, the glViewport call is invalid.

We can call stubInit() from all the wgl/glx functions in the faker. 
It returns immediately if it's been called before.

-Brian


Ricky Uy wrote:
> You're right, I found the article you mentioned on MSDN. But if that is 
> the case, then are applications like Celestia doomed to be able to work 
> on Chromium in their original, unmodified state? In it's unmodified 
> state, stubInit() is never going to be called before the glViewport() 
> call, and I don't see any other areas of the crfaker dll where the call 
> to stubInit() would make sense. Celestia will just call glViewport and 
> it will immediately get intercepted by windows_exports.c and try to jmp 
> to an invalid location. I suppose checks could be made in the 
> windows_exports file to see if stubInit has already been called or not, 
> but it wouldn't be good to make function calls like that inside of NAKED 
> functions. Do you know any other places that might be okay for it?
> 
> */Greg Humphreys /* wrote:
> 
> If I recall correctly, this is (was?) explicitly documented in MSDN as
> being illegal (manual loading of other DLL's within DLLMain). It USED
> to be there, and then I discovered this, and moved it.
> 
> --
> Greg Humphreys, Assistant Professor
> Department of Computer Science, University of Virginia
> http://www.cs.virginia.edu/~humper/
> 
> 
> On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:
> 
> > Hi,
> >
> > For the Windows version of this library, there should be a call to
> > stubInit() just before the return in DLLMain() in load.c, and all
> the
> > calls to stubInit() should be removed from the wgl functions in
> wgl.c.
> > There were several applications that would bail out because of this,
> > including Celestia for Windows. However with this patch, they all
> > work.
> >
> > The problem was that some applications d on't call wgl functions
> before
> > trying to do other things. For example, especially in direct
> response
> > to Alicia's post, Celestia would try to call ShowWindow() before
> > calling ChoosePixelFormat(). This caused a crash because ShowWindow
> > makes a call to glViewport, and because stubInit() had not yet been
> > called, the glim dispatch table was nulled out. So there was a
> crash.
> > By having stubInit() in DLLMain, issues like these are resolved.
> > 
> > Now there was a comment above DLLMain saying that Windows didn't
> allow
> > the loading of other libraries in DLLMain, and I'm not sure what has
> > happened since, but it works fine. Hope this helps some people with
> > their applications.
> >
> > Ricky
> >
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Brief ings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail 
> 
> - Send 10MB messages!



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Chromium-dev mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chromium-dev


---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

		
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.

Re: [Chromium-dev] crfaker fix

[Ricky Uy <ric...@ya...>]

I tried putting the stubInit() in all the WGL calls like you suggested, but it doesn't resolve the issue. I also have all the wgl intercepted calls printing out to a file, and it appears that celestia is not calling any wgl functions before it calls ShowWindow() (and thus glViewport). Perhaps the celestia code is done a little sloppy with the window setup (like the way it calls choosepixelformat AFTER showwindow), but chromium _should_ still be able to handle this properly.
 
Ricky

Brian Paul <bri...@tu...> wrote:

There must be _some_ WGL function being called before glViewport. At 
least wglMakeCurrent() must be called to bind a rendering context. 
Otherwise, the glViewport call is invalid.

We can call stubInit() from all the wgl/glx functions in the faker. 
It returns immediately if it's been called before.

-Brian


Ricky Uy wrote:
> You're right, I found the article you mentioned on MSDN. But if that is 
> the case, then are applications like Celestia doomed to be able to work 
> on Chromium in their original, unmodified state? In it's unmodified 
> state, stubInit() is never going to be called before the glViewport() 
> call, and I don't see any other areas of the crfaker dll where the call 
> to stubInit() would make sense. Celestia will just call glViewport and 
> it will immediately get intercepted by windows_exports.c and try to jmp 
> to an invalid location. I suppose checks could be made in the 
> windows_exports file to see if stubInit has already been called or not, 
> but it wouldn't be good to make function calls like that inside of NAKED 
> functions. Do you know any other places that might be okay for it?
> 
> */Greg Humphreys /* wrote:
> 
> If I recall correctly, this is (was?) explicitly documented in MSDN as
> being illegal (manual loading of other DLL's within DLLMain). It USED
> to be there, and then I discovered this, and moved it.
> 
> --
> Greg Humphreys, Assistant Professor
> Department of Computer Science, University of Virginia
> http://www.cs.virginia.edu/~humper/
> 
> 
> On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:
> 
> > Hi,
> >
> > For the Windows version of this library, there should be a call to
> > stubInit() just before the return in DLLMain() in load.c, and all
> the
> > calls to stubInit() should be removed from the wgl functions in
> wgl.c.
> > There were several applications that would bail out because of this,
> > including Celestia for Windows. However with this patch, they all
> > work.
> >
> > The problem was that some applications d on't call wgl functions
> before
> > trying to do other things. For example, especially in direct
> response
> > to Alicia's post, Celestia would try to call ShowWindow() before
> > calling ChoosePixelFormat(). This caused a crash because ShowWindow
> > makes a call to glViewport, and because stubInit() had not yet been
> > called, the glim dispatch table was nulled out. So there was a
> crash.
> > By having stubInit() in DLLMain, issues like these are resolved.
> >
> > Now there was a comment above DLLMain saying that Windows didn't
> allow
> > the loading of other libraries in DLLMain, and I'm not sure what has
> > happened since, but it works fine. Hope this helps some people with
> > their applications.
> >
> > Ricky
> >
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Brief ings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail 
> 
> - Send 10MB messages!



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Chromium-dev mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chromium-dev

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

Re: [Chromium-dev] crfaker fix

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

There must be _some_ WGL function being called before glViewport.  At 
least wglMakeCurrent() must be called to bind a rendering context. 
Otherwise, the glViewport call is invalid.

We can call stubInit() from all the wgl/glx functions in the faker. 
It returns immediately if it's been called before.

-Brian


Ricky Uy wrote:
> You're right, I found the article you mentioned on MSDN. But if that is 
> the case, then are applications like Celestia doomed to be able to work 
> on Chromium in their original, unmodified state? In it's unmodified 
> state, stubInit() is never going to be called before the glViewport() 
> call, and I don't see any other areas of the crfaker dll where the call 
> to stubInit() would make sense. Celestia will just call glViewport and 
> it will immediately get intercepted by windows_exports.c and try to jmp 
> to an invalid location. I suppose checks could be made in the 
> windows_exports file to see if stubInit has already been called or not, 
> but it wouldn't be good to make function calls like that inside of NAKED 
> functions. Do you know any other places that might be okay for it?
> 
> */Greg Humphreys <hu...@cs...>/* wrote:
> 
>     If I recall correctly, this is (was?) explicitly documented in MSDN as
>     being illegal (manual loading of other DLL's within DLLMain). It USED
>     to be there, and then I discovered this, and moved it.
> 
>     --
>     Greg Humphreys, Assistant Professor
>     Department of Computer Science, University of Virginia
>     http://www.cs.virginia.edu/~humper/
> 
> 
>     On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:
> 
>      > Hi,
>      >
>      > For the Windows version of this library, there should be a call to
>      > stubInit() just before the return in DLLMain() in load.c, and all
>     the
>      > calls to stubInit() should be removed from the wgl functions in
>     wgl.c.
>      > There were several applications that would bail out because of this,
>      > including Celestia for Windows. However with this patch, they all
>      > work.
>      >
>      > The problem was that some applications d on't call wgl functions
>     before
>      > trying to do other things. For example, especially in direct
>     response
>      > to Alicia's post, Celestia would try to call ShowWindow() before
>      > calling ChoosePixelFormat(). This caused a crash because ShowWindow
>      > makes a call to glViewport, and because stubInit() had not yet been
>      > called, the glim dispatch table was nulled out. So there was a
>     crash.
>      > By having stubInit() in DLLMain, issues like these are resolved.
>      >
>      > Now there was a comment above DLLMain saying that Windows didn't
>     allow
>      > the loading of other libraries in DLLMain, and I'm not sure what has
>      > happened since, but it works fine. Hope this helps some people with
>      > their applications.
>      >
>      > Ricky
>      >
>      > Do you Yahoo!?
>      > New and Improved Yahoo! Mail - Send 10MB messages!
> 
> 
> 
>     -------------------------------------------------------
>     This SF.Net email sponsored by Black Hat Brief ings & Training.
>     Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>     digital self defense, top technical experts, no vendor pitches,
>     unmatched networking opportunities. Visit www.blackhat.com
>     _______________________________________________
>     Chromium-dev mailing list
>     Chr...@li...
>     https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail 
> <http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html> 
> - Send 10MB messages!

Re: [Chromium-dev] crfaker fix

[Ricky Uy <ric...@ya...>]

You're right, I found the article you mentioned on MSDN. But if that is the case, then are applications like Celestia doomed to be able to work on Chromium in their original, unmodified state? In it's unmodified state, stubInit() is never going to be called before the glViewport() call, and I don't see any other areas of the crfaker dll where the call to stubInit() would make sense. Celestia will just call glViewport and it will immediately get intercepted by windows_exports.c and try to jmp to an invalid location. I suppose checks could be made in the windows_exports file to see if stubInit has already been called or not, but it wouldn't be good to make function calls like that inside of NAKED functions. Do you know any other places that might be okay for it?


Greg Humphreys <hu...@cs...> wrote:
If I recall correctly, this is (was?) explicitly documented in MSDN as 
being illegal (manual loading of other DLL's within DLLMain). It USED 
to be there, and then I discovered this, and moved it.

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/


On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:

> Hi,
>
> For the Windows version of this library, there should be a call to 
> stubInit() just before the return in DLLMain() in load.c, and all the 
> calls to stubInit() should be removed from the wgl functions in wgl.c. 
> There were several applications that would bail out because of this, 
> including Celestia for Windows. However with this patch, they all 
> work.
>
> The problem was that some applications don't call wgl functions before 
> trying to do other things. For example, especially in direct response 
> to Alicia's post, Celestia would try to call ShowWindow() before 
> calling ChoosePixelFormat(). This caused a crash because ShowWindow 
> makes a call to glViewport, and because stubInit() had not yet been 
> called, the glim dispatch table was nulled out. So there was a crash. 
> By having stubInit() in DLLMain, issues like these are resolved.
>
> Now there was a comment above DLLMain saying that Windows didn't allow 
> the loading of other libraries in DLLMain, and I'm not sure what has 
> happened since, but it works fine. Hope this helps some people with 
> their applications.
>
> Ricky
>
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Chromium-dev mailing list
Chr...@li...
https://lists.sourceforge.net/lists/listinfo/chromium-dev

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

Re: [Chromium-dev] crfaker fix

[Greg H. <hu...@cs...>]

If I recall correctly, this is (was?) explicitly documented in MSDN as 
being illegal (manual loading of other DLL's within DLLMain).  It USED 
to be there, and then I discovered this, and moved it.

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/


On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:

> Hi,
>
> For the Windows version of this library, there should be a call to 
> stubInit() just before the return in DLLMain() in load.c, and all the 
> calls to stubInit() should be removed from the wgl functions in wgl.c. 
> There were several applications that would bail out because of this, 
> including Celestia for Windows. However with this patch, they all 
> work.
>
> The problem was that some applications don't call wgl functions before 
> trying to do other things. For example, especially in direct response 
> to Alicia's post, Celestia would try to call ShowWindow() before 
> calling ChoosePixelFormat(). This caused a crash because ShowWindow 
> makes a call to glViewport, and because stubInit() had not yet been 
> called, the glim dispatch table was nulled out. So there was a crash. 
> By having stubInit() in DLLMain, issues like these are resolved.
>
> Now there was a comment above DLLMain saying that Windows didn't allow 
> the loading of other libraries in DLLMain, and I'm not sure what has 
> happened since, but it works fine. Hope this helps some people with 
> their applications.
>
> Ricky
>
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!

[Chromium-dev] crfaker fix

[Ricky Uy <ric...@ya...>]

Hi,

For the Windows version of this library, there should be a call to stubInit() just before the return in DLLMain() in load.c, and all the calls to stubInit() should be removed from the wgl functions in wgl.c. There were several applications that would bail out because of this, including Celestia for Windows. However with this patch, they all work.

The problem was that some applications don't call wgl functions before trying to do other things. For example, especially in direct response to Alicia's post, Celestia would try to call ShowWindow() before calling ChoosePixelFormat(). This caused a crash because ShowWindow makes a call to glViewport, and because stubInit() had not yet been called, the glim dispatch table was nulled out. So there was a crash. By having stubInit() in DLLMain, issues like these are resolved.

Now there was a comment above DLLMain saying that Windows didn't allow the loading of other libraries in DLLMain, and I'm not sure what has happened since, but it works fine. Hope this helps some people with their applications.

Ricky

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

Re: [Chromium-dev] Darwin Port

[Greg H. <hu...@cs...>]

I'm definitely interested!

--
Greg Humphreys, Assistant Professor
Department of Computer Science, University of Virginia
http://www.cs.virginia.edu/~humper/


On Jun 22, 2004, at 5:32 PM, Christopher Waters wrote:

> Is anyone else actively working on getting Darwin to work?  I have 
> spent a good amount of time on just that, and was wondering if anyone 
> else has made any progress.
>
> Currently, I have everything working (I hope) -except- for the faker 
> library, which is posing quite some problems in the faking area. 
> (dynamic linker = evil)
>
> If anyone is interested in what I've done, I can send out a copy of 
> the change log I've been making, or even the files.  Actually, I'm 
> currently rewriting that log to be more concise about what exactly was 
> changed. =)
>
>  -Chris Waters
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

[Chromium-dev] Darwin Port

[Christopher W. <cr...@ms...>]

Is anyone else actively working on getting Darwin to work?  I have 
spent a good amount of time on just that, and was wondering if anyone 
else has made any progress.

Currently, I have everything working (I hope) -except- for the faker 
library, which is posing quite some problems in the faking area. 
(dynamic linker = evil)

If anyone is interested in what I've done, I can send out a copy of the 
change log I've been making, or even the files.  Actually, I'm 
currently rewriting that log to be more concise about what exactly was 
changed. =)

  -Chris Waters

[Chromium-dev] Re: ADDRINFO use [Was: Windows breakage with cr_net.h]

[Samuel T. <sam...@en...>]

Le mar 22 jun 2004 =E0 08:31:25 -0700, Mike Houston a tapot=E9 sur son cl=
avier :
> Samuel Thibault wrote:
> >Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son=
 clavier=20
> >:
> >>The other oddity is that the changes to support IPv6 seem to always k=
ick=20
> >>us into using ADDRINFO on recent versions of Linux.  This works,
> >
> >Of course it does, to support IPv6 whenever available. getaddrinfo()'s
> >interface was specially design to always work: the dns lookup may
> >report ipv4 and ipv6 addresses, getaddrinfo() gives them all. If an
> >ipv6 address is given but doesn't work either because lack of support
> >in the kernel (ENOAFSUPPORT) or for network reasons, the connection
> >will revert back to ipv4.
>=20
> I understand why it works, I just thought it was odd to ALWAYS use it.

The getaddrinfo() way is quite better in many ways: since it may return
several addresses, hosts with multiple ips may be correctly handled:
every ip will be tried until one works.

> some TOE's and most of the IP interception routines for highspeed
> networks only work if AF_INET is used.

Ah, ok. For this, just make sure that dns replies don't give any ipv6
address, and it will work. If needed, use a special dns entry.

> My point is whether we should use AF_INET in general and detect
> IPv6 another way.

The user may set IPv6 addresses by hand, but for this, getaddrinfo()
must be used. Using getaddrinfo() replies for determining whether
IPv6 is possible (or asked by hand) really is the fine way.

> Is anyone using IPv6?

Yes, some people at the INSA of Lyon actually contacted me because they
needed IPv6 working.

> How often does anyone need to run IPv6 across a cluster?

Well, IPv6 is actually in several ways more efficient that IPv4, and QoS
is quite better supported.

> Is it really just for remote stream support?

I guess people at INSA use Chromium over VTHD, a very high bandwidth
WAN used for research. IPv6's QoS is quite useful there for instance.

Regards,
Samuel Thibault

Re: [Chromium-dev] Windows breakage with cr_net.h

[Samuel T. <sam...@en...>]

Le mar 22 jun 2004 =E0 08:32:37 -0700, Mike Houston a tapot=E9 sur son cl=
avier :
> Samuel Thibault wrote:
>=20
> >Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son=
 clavier=20
> >:
> >>I noticed that we are trying to include sys/socket.h on ALL platforms=
. =20
> >>We shouldn't be doing this under Windows.  I'll be checking in a fix=20
> >>shortly.
> >
> >Is netdb.h available under Windows ? It happens to seem to provide
> >AF_INET6 under linux, but I'm really not sure. The tests I could see i=
n
> >configure.in scripts was always to use <sys/socket.h>
> >=20
> >
> No.  Windows doesn't yet support IPv6, at least in a standard posix man=
ner.

Yes, I know, but netdb.h also provides gethostbyname & co, I wonder
where they are defined under Windows.

Oops, sorry, misexplaining: I wanted to say that netdb.h seems to
include sys/socket.h itself so that we could replace
#include <sys/socket.h> by #include <netdb.h> and remove #ifndef WIN,
but for this, netdb.h is needed even in windows.

Regards,
Samuel

Re: [Chromium-dev] The tcpip layer is really frustrating me

[Mike H. <mho...@gr...>]

Keith Whitwell wrote:

> Mike Houston wrote:
>
>> The main issue here is time.  I'll be at ATI this summer, so I don't 
>> have the time to deal with a network layer rewrite just now.
>>
>> The main issue with the tcpip layer is how we handle mothership 
>> connections.  We really should use special calls for mothership 
>> connections so that we don't pollute the rest of the network layer.  
>> The mothership connections do not stay live, but the tcpip layer 
>> still checks them in a tight loop.  This isn't a huge hit, but is 
>> does have an impact on other layers.
>
>
> I don't understand - why are connections that are known not to be live 
> ever examined again?

Because num_conns at line ~782 also counts mothership connections made 
at startup.  Usually, the connections are dropped and we bail out on the 
connection at ~line 785.  However, we still run through all connections 
and do a pointer dereference.  Where things get interesting are in non 
connection-based layers like IB, GM, and maybe Quadrics (Joel Welling 
would be the person to ask here).  The problem is that the connections 
are NOT closed becuase the connection semantics are being handled 
through the mothership.  The tcpip layer holds a connection open so that 
we can try to cleanly take down other nodes.

We do need to monitor these, but since data is not being sent, we get 
stuck on timeouts in the tcpip layer which creams performance.

>
>> At the moment, I have some really hacky code that forces the tcpip 
>> layer to bypass if the only connections are mothership connections.  
>> This helps to speed things up a little. 
>
>
> Can you post that code?  Or send it to me privately if you'd rather?

I won't have access to the code until this weekend as I'm officially at 
ATI this summer. 

Basically I hacked the conn structs to mark whether or not things were 
mothership connections.  If they were, I skip over them in crTCPIPRecv.  
This does speed things up on IB and GM, but completely fubars their 
ability to cleanly exit when a node is killed.  I have to manually kill 
all of the crservers/crappfakers when this happens.  This is obviously 
not an acceptable solution.

What would be nice to see would be a mothership connection library.  
This would *hopefully* remove some of the complexity from the tcpip 
layer, and allow us to better handle faking connection managers.  The 
tcpip layer is currently a little brittle because of all of the 
hackiness to get the mothership to behave.

-Mike

Re: [Chromium-dev] Windows breakage with cr_net.h

[Mike H. <mho...@gr...>]

Samuel Thibault wrote:

>Le lun 21 jun 2004 à 17:23:28 -0700, Mike Houston a tapoté sur son clavier :
>  
>
>>I noticed that we are trying to include sys/socket.h on ALL platforms.  
>>We shouldn't be doing this under Windows.  I'll be checking in a fix 
>>shortly.
>>    
>>
>
>Is netdb.h available under Windows ? It happens to seem to provide
>AF_INET6 under linux, but I'm really not sure. The tests I could see in
>configure.in scripts was always to use <sys/socket.h>
>  
>
No.  Windows doesn't yet support IPv6, at least in a standard posix manner.

-Mike

[Chromium-dev] Re: ADDRINFO use [Was: Windows breakage with cr_net.h]

[Mike H. <mho...@gr...>]

Samuel Thibault wrote:

>Hi
>
>Le lun 21 jun 2004 à 17:23:28 -0700, Mike Houston a tapoté sur son clavier :
>  
>
>>The other oddity is that the changes to support IPv6 seem to always kick 
>>us into using ADDRINFO on recent versions of Linux.  This works,
>>    
>>
>
>Of course it does, to support IPv6 whenever available. getaddrinfo()'s
>interface was specially design to always work: the dns lookup may
>report ipv4 and ipv6 addresses, getaddrinfo() gives them all. If an
>ipv6 address is given but doesn't work either because lack of support
>in the kernel (ENOAFSUPPORT) or for network reasons, the connection
>will revert back to ipv4.
>  
>
I understand why it works, I just thought it was odd to ALWAYS use it.

>  
>
>>but moves all streams to PF instead of AF.
>>    
>>
>
>PF / AF ??
>That means Protocol Family / Address Family.
>
>There's actually no difference between them, except maybe some minor
>differences in the numbering (there is none under linux for instance),
>and the *good* one to use for getaddrinfo in the hints structure *is*
>PF_something, since we tell the Protocol Family we'd like to use for
>conencting (here, unspecified). Then getaddrinfo may report
>AF_something to tell which address family it found. I just checked
>this once again in Gisèle Cizault's book "IPv6 Théorie et pratique"
>  
>
I don't have a problem with supporting IPv6 correctly, but some TOE's 
and most of the IP interception routines for highspeed networks only 
work if AF_INET is used.  For the later, you can use LD_PRELOAD to 
automatically kick some IP connections to SocketsGM, SDP, IP over 
Quadrics, etc.  But, this only works if AF_INET is used...  Since SDP 
has it's own layer now, this becomes a little less important.

>  
>
>>Things work, I just want to point out that this probably shouldn't
>>be default behavior.  We probably only really want to kick across
>>to PF streams when actually using IPv6 to connect.
>>    
>>
>
>Currently, we actually *precisely* use PF_INET when not using IPv6 to
>connect.
>  
>
Sorry for the misunderstanding here.  My point is whether we should use 
AF_INET in general and detect IPv6 another way.  Is anyone using IPv6?  
How often does anyone need to run IPv6 across a cluster?  Is it really 
just for remote stream support?

-Mike

>Regards,
>Samuel Thibault
>  
>

Re: [Chromium-dev] The tcpip layer is really frustrating me

[Keith W. <ke...@tu...>]

Mike Houston wrote:
> The main issue here is time.  I'll be at ATI this summer, so I don't 
> have the time to deal with a network layer rewrite just now.
> 
> The main issue with the tcpip layer is how we handle mothership 
> connections.  We really should use special calls for mothership 
> connections so that we don't pollute the rest of the network layer.  The 
> mothership connections do not stay live, but the tcpip layer still 
> checks them in a tight loop.  This isn't a huge hit, but is does have an 
> impact on other layers.

I don't understand - why are connections that are known not to be live ever 
examined again?

> At the moment, I have some really hacky code that forces the tcpip layer 
> to bypass if the only connections are mothership connections.  This 
> helps to speed things up a little. 

Can you post that code?  Or send it to me privately if you'd rather?

Keith

Re: [Chromium-dev] Windows breakage with cr_net.h

[Samuel T. <sam...@en...>]

Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son cl=
avier :
> I noticed that we are trying to include sys/socket.h on ALL platforms. =
=20
> We shouldn't be doing this under Windows.  I'll be checking in a fix=20
> shortly.

Is netdb.h available under Windows ? It happens to seem to provide
AF_INET6 under linux, but I'm really not sure. The tests I could see in
configure.in scripts was always to use <sys/socket.h>

Regards,
Samuel Thibault