[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [PATCH 1/2] Framebuffer split

From: Vladimir 'phcoder' Serbinenko
Subject: Re: Fwd: [PATCH 1/2] Framebuffer split
Date: Sun, 2 Aug 2009 23:52:42 +0200

>> >> +#define grub_video_render_target grub_video_fbrender_target
>> >
>> > If we want to rename this function, I'd rather do it all the way than
>> > keeping a compatibility macro.  But then, I'd also prefer if this is
>> > done separately from the rest (either before or after).
>> >
>> It's not about renaming but to inform includes that
>> grub_video_render_target is in fact grub_video_fbrender_target and so
>> avoid warnings and casts.
> I don't understand this.  If we want to settle with grub_video_render_target
> why don't we just provide that function directly?  Or is this making room
> for an additional layer later on?

It's for abstraction we already have. Most of video subsystem doesn't
care whether render_target is framebuffer, OpenGL or network commands.
In this particular case we know that we're rendering to a framebuffer
and so function
do_something (grub_video_render_target *my_render_target);
like it's used by upper layers is inded the same as
do_something (grub_video_fbrender_target *my_render_target);
and not e.g.
do_something (grub_video_glrender_target *my_render_target);
> --
> Robert Millan
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]