| Newsgroups |
gmane.comp.graphics.y.devel |
| Message-ID |
<[email protected]> |
I don't usually play the part of Billy-goat Gruff, but anyway...
Quoting Jost Boekemeier <[email protected]>:
> > Implement a shared memory transport mechanism -- should give local apps a
> > bit of a speed boost.
>
> Nonsense. Latency is your enemy, not bandwidth...
And where did I mention bandwidth?
The latency of a synchronised shared memory system is a lot lower than that of a
network protocol (even over local loopback or unix sockets). Shared memory does
not involve the kernel _at all_. You avoid 2 syscalls per transaction.
> So nuke the current protocol and send a high level description to the
> server. Be careful to not make the network split at widget-level but on
> component-level.
I'll take a look at the current protocol before I think about changing it.
Also, as far as there's any distinction between a widget and a component, I
understand widget to be the view of a classic gui srchitecture and component to
encompass that and some elements of model and controller. For the majority of
resources (contents of lists, trees etc) I can see no good reason to mandate
that they be on the server (and plenty which make me want to ensure they're
not).
> > Get a list of every known widget
>
> Doesn't work (this has already discussed to death, so I wan't explain it
> again). The only sane way to implement the "widget server" is to make
> the widgets transferable.
Not going to implement every known widget, just all the useful ones (viz, those
in the other toolkit's core set) and provide a callback proxy widget which will
behave as the server-side presence of those we haven't implemented.
> > Build all the regular desktop apps (file manager,
>
> You cannot start designing apps when even the basics are not
> implemented.
That's a CGSM*. How do you know what you need if you don't have use cases?
It's a lot easier to build your apps with stub calls so you know what kind of
API is going to be useful *before* you invest a lot of time implementing.
> > Suspend/resume of entire Y sessions
>
> Not possible.
Prove it. Mathematically.
A truer statement would be "Very Hard".
> > XFree86/X.Org driver stealing.
>
> Huh!? What do you want to steal? (I am starting to think that this is
> a fake post, but anyway)
If Y can talk enough like X that the accelerated X drivers can't tell the
difference, we get a massive amount of hardware coverage, without having to
worm the specs of card out of manufacturers.
> > Port Gecko (probably as a widget)
>
> I think I should stop here. You have definitely much to learn. I
> suggest to start looking at kdrive, glitz and cairo for the backend and
> XUL for the frontend. You should also take a look at DirectX9 instead of
> OpenGL, because OpenGL is *not* a good target for hardware 2d
> acceleration (see david reeveman's post). A good start would also
> probably the design of the Avalon graphics system, especially the MIL.
I am always happy to learn, although I prefer it to come from someone with less
of a 'tood. It's probably worth noting that I didn't mention OpenGL in the
context of providing 2D acceleration.
> But first of all it is necessary to understand that X is only a HAL, it
> is an abstraction which transforms input events, defines and operates
> on shapes. But a widget server is located on top of this HAL, it
> accepts huge scene graphs from the users and splits them so that the HAL
> can consume them. It is important to not mix the two technologies.
I know what X is. I reject your last statement as unjustified.
Phil
* See "Yes Minister" Series 1.