On Fri, 14 Sep 2001, Brian S. Julin wrote:
> Hi,
>
> I am finally back from being stranded in the Boston area while
> waiting for an automobile part to arrive. Time to get back to
> work.
>
> The first thing I'd like to do is fix a bug I introduced
> with the config file changes in the fbdev target. Basically
> the bug may allow unaccelerated primitives to draw while an
> accel is still running, because the old code used to
> prognosticate as to whether the rendering library should load
> the pixela functions vs the regular pixel functions (one
> calls waitidleaccel, the other does not.)
>
> I think it was bad in the first place that the renderers check
> the needidleaccel flag to decide what to load when they are
> initialized, as it complicates the overloading process requiring
> one to know before dlopening a core renderer whether an accelerated
> renderer would be loaded over it.
>
> What I want to do is allow the renderers to switch between the
> pixela and pixel functions during runtime, not just when dlopened.
> This would be done whenever ggiSetFlags is called. I would also
> like to pass information about changes to the visual flags on to
> extensions via ggiIndicateChange.
>
> This would involve two things: the first would be an additional
> value for ggiIndicateChange, GGI_CHG_VISFLAGS, which would
> be sent to all extensions whenever ggiSetFlags is called.
>
> The second would be a function hook added to each rendering/color/display
> dl which would be called whenever SetFlags is called, OR, it could
> also be done by adding separate pixela/pixel primitive hooks to
> the drawops structure. The former would add yet another function to
> each and every renderer, while the latter would offer less extensibility
> for any similar needs in the future and use up a lot of hooks in the
> renderer.
>
> The procedure on a setflags would be to inform the ggi drawops/color
> renderers first, then to inform the extensions. The procedure on a setmode
> would be to load all dls, ggiIndicateChange for an API change, then when
> that is done, run the same procedure as setflags uses to adjust the
> loaded libraries to the current/default flags state.
>
> Does anyone see a problem with this, or have a better idea?
>
> Also, it is starting to become a commonly used workaround to
> do things roughly similar to this to deal with precedence of
> functions during getapi traversals:
>
> static int dummyfunc(void) {
> {
> return -1;
> }
>
> int ggiFooAttach(ggi_visual_t vis)
> {
>
> /* ... */
>
> LIBGGI_FOOEXT(vis)->dummy = (void *)dummyfunc;
>
> /* ... */
>
> }
>
>
> /* Stubs target */
> static int GGIopen(ggi_visual *vis, struct ggi_dlhandle *dlh,
> const char *args, void *argptr, uint32 *dlret)
> {
> if (LIBGGI_FOOEXT(vis)->func1 == LIBGGI_FOOEXT(vis)->dummy) {
> LIBGGI_FOOEXT(vis)->func1 = FOO_Stubs_Func1;
> }
>
> ... a similar comparison would be used by the renderers to decide
> whether or not they own a pixel function and should switch it to their
> pixela function, or visa versa. Is this OK, or is it something that
> will break on certain systems with lame compilers and we just haven't
> noticed yet? Seems to me to be safe, but I figured I'd ask.
Hi!
I see even one more problem with overloading refering to the extensions.
libggi uses getapi() to reload sub-libs in default/*
libbuf uses getapi() to reload sub-libs in default/*
libblt will use getapi() to reload sub-libs in default/*
libxmi will use getapi() to reload sub-libs in default/*
So where is the problem? The problem will come with libxmi as soon as it
is going to use libbuf and libblt internally.
libxmi must overload getapi(), it must call the getapi() from both libbuf
and libblt and their getapi() must call the one from libggi.
With the current overloading scheme you will run into heavy trouble.
IMHO the overloading scheme should be implemented in a way that gives
a real C++ feeling to the programmer.
Any ideas?
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
