Re: [Chromium-users] Tilesort generates needed network traffic?

[James S. <arr...@gm...>]

I am trying to figure out how this all fits together. Right now I know
so little about the interactions between the various components that I
can't begin to figure out how to fix things.

I have been looking at the packer source code, I can't figure out how
the buffer to write to is set? I see macros that write data, and I see
a macro to grab the packer context. From the packer context the
functions are able to get a pointer a buffer. Normally write functions
take some kind of stream identifier, but Chromium appears to use a
global variable rather than a function argument. This makes tracking
down exactly how the buffer to write to gets set a bit tricky. Do you
have any idea how I can figure out were it is getting set?

I am not sure how much of the problem I am experiencing has to do with
the state tracker. I don't think we should have to send anything at
all to a Render SPU if the window being rendered to is not on that
SPUs server. I can't be sure, as I am very confused about how the
buffer to be written gets selected, but it looks as if the SwapBuffers
command is being sent to all Render SPUs unconditionally in
tilesortspu_SwapBuffers rather than to just the Render SPUs that have
the Render window on them? Is there a technical reason for this, or
has no one got around to optimizing it yet?

How does the State Tracker interact with the rest of Chromium? To me
it appears as if it is used to track the difference between the OpenGL
state on the tilesort SPU and the OpenGL state on the Render SPU. Does
it do anything else? To me it appears that the State Tracker is simply
something else uses to keep track of the state defences, it looks as
if something else is actually making the choice to not send something
to some Render SPUs and then using the State Tracker to keep track the
the results of this choice? If this is correct, what code is actually
making this choice?

Thank you for your time,
James Steven Supancic III