Menu
▾
▴
chromium-dev
|
From: <ma...@co...> - 2005-06-08 23:39:03
|
Hi all, So it appears that render_to_app_window doesn't work under Windows. There's even a comment in the code (in renderspu_wgl.c) that says: /* The render_to_app_window option * is set and we've got a nativeWindow * handle, save the handle for * later calls to swapbuffers(). * * NOTE: This doesn't work, except * for software driven Mesa. * We'd need to object link the * crappfaker and crserver to be able to share * the HDC values between processes.. FIXME! */ So, what I'm planning on trying is the following: Add a dispatch table to stub called stubDoubleDispatch. The functions in it would call stubNativeDispatch.func(someArgs) and stubSpuDispatch.func (someArgs). Does anyone forsee a problem with this? Thanks, Jon |
|
From: Mike H. <mho...@gr...> - 2005-06-09 00:03:08
|
The main issue on the windows side is someone figuring out how to pass the gid(?) information around so Chromium can grab the window. Under *nix, this is pretty easy through X11. I would suggest following along the X11 path and see if something similar can be done on the Windows path. -Mike ma...@co... wrote: >Hi all, > >So it appears that render_to_app_window doesn't work under Windows. > >There's even a comment in the code (in renderspu_wgl.c) that says: > >/* The render_to_app_window option > * is set and we've got a nativeWindow > * handle, save the handle for > * later calls to swapbuffers(). > * > * NOTE: This doesn't work, except > * for software driven Mesa. > * We'd need to object link the > * crappfaker and crserver to be able to share > * the HDC values between processes.. FIXME! >*/ > >So, what I'm planning on trying is the following: > >Add a dispatch table to stub called stubDoubleDispatch. The functions in it >would call stubNativeDispatch.func(someArgs) and stubSpuDispatch.func >(someArgs). > >Does anyone forsee a problem with this? > >Thanks, >Jon > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput >a projector? How fast can you ride your desk chair down the office luge track? >If you want to score the big prize, get to know the little guy. >Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 >_______________________________________________ >Chromium-dev mailing list >Chr...@li... >https://lists.sourceforge.net/lists/listinfo/chromium-dev > > |
|
From: <ma...@co...> - 2005-06-09 00:55:20
|
Mike, Thanks for the suggestion, but I think that concept has led to the Windows render-to-app-window problem in the first place... I think the problem is that one processes can't render into another's Window (window id's might be process- specific ) I don't know for sure what the cause is, but the existing implementation definitely doesn't work! In the meantime, I went ahead with my plan and it looks like it works! (For single window apps anyway... and so far I've only tried city...) Having the stub itself double dispatch to the spus and the app window should be higer performance anyway, since you're not sending the calls off to another process, right? The only tricky part is handling which context is the current native context, but another half day and a hash table or two should settle that... Thanks, Jon ps. The IEEE Vis talk that you, Brian, et. al. put on has been super valuable. Thanks again for having done that! Will there be another this year? Jonathan Marbach BP Center for Visualization University of Colorado Quoting Mike Houston <mho...@gr...>: > The main issue on the windows side is someone figuring out how to pass > the gid(?) information around so Chromium can grab the window. Under > *nix, this is pretty easy through X11. I would suggest following along > the X11 path and see if something similar can be done on the Windows path. > > -Mike > |
|
From: <mho...@gr...> - 2005-06-09 19:54:53
|
I think you might be misunderstanding the purpose of render-to-app-window. What you have built is effectively a "T" SPU. Allowing the window to be drawn by the original app as well as feed the Chromium SPUs. render-to-app-window as currently written means that after the stream has gone through transformations, the render spu will use the original app window to render to instead of putting up it's own window. For example, you might use Chromium to change the colors of vertices in the application, and instead of rendering to a separate window, you want to replace the original app's rendering. What you have made has actually been requested by many in the past. The main issue with your approach is that it will show the app rendering prior to stream tranformations. It's still very useful for tiled display work however... -Mike > Mike, > > Thanks for the suggestion, but I think that concept has led to the Windows > render-to-app-window problem in the first place... I think the problem is > that > one processes can't render into another's Window (window id's might be > process- > specific ) I don't know for sure what the cause is, but the existing > implementation definitely doesn't work! > > In the meantime, I went ahead with my plan and it looks like it works! > (For > single window apps anyway... and so far I've only tried city...) > > Having the stub itself double dispatch to the spus and the app window > should > be higer performance anyway, since you're not sending the calls off to > another > process, right? > > The only tricky part is handling which context is the current native > context, > but another half day and a hash table or two should settle that... > > Thanks, > Jon > > ps. The IEEE Vis talk that you, Brian, et. al. put on has been super > valuable. > Thanks again for having done that! Will there be another this year? > > > Jonathan Marbach > BP Center for Visualization > University of Colorado > > > Quoting Mike Houston <mho...@gr...>: > >> The main issue on the windows side is someone figuring out how to pass >> the gid(?) information around so Chromium can grab the window. Under >> *nix, this is pretty easy through X11. I would suggest following along >> the X11 path and see if something similar can be done on the Windows >> path. >> >> -Mike >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > |
|
From: <ma...@co...> - 2005-06-09 20:56:36
|
Mike, You're right - that is an advantage of the render-to-app-window feature. I think in general, if my changes get back into the tree, we'd just have to make sure users understand the tradeoffs between one way and the other. > It's still very useful for tiled display work however... Probably the #1 use for Chromium right now... right? Anyway, thanks for your input! What would be a good name for an ENV variable to toggle "my" new feature. Jon Quoting mho...@gr...: > I think you might be misunderstanding the purpose of render-to-app-window. > What you have built is effectively a "T" SPU. Allowing the window to be > drawn by the original app as well as feed the Chromium SPUs. > render-to-app-window as currently written means that after the stream has > gone through transformations, the render spu will use the original app > window to render to instead of putting up it's own window. For example, > you might use Chromium to change the colors of vertices in the > application, and instead of rendering to a separate window, you want to > replace the original app's rendering. > > What you have made has actually been requested by many in the past. The > main issue with your approach is that it will show the app rendering prior > to stream tranformations. It's still very useful for tiled display work > however... > > -Mike > |
|
From: Sean A. <sea...@ll...> - 2005-06-09 21:21:17
|
ma...@co... wrote: > What would be a good name for an ENV variable to toggle "my" new > feature. I would suggest making it a server variable in the mothership python configuration file rather than an environment variable. -Sean __ sea...@ll... 925-422-1648 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X