Re: Render to App Window... On Windows?

[email protected] Thu, 9 Jun 2005 12:54:45 -0700 (PDT)
Newsgroups gmane.comp.graphics.chromium.devel
Message-ID <[email protected]>
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 <[email protected]>:
>
>> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>



-------------------------------------------------------
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