All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Rydberg <jrydberg@night.trouble.net>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: New patch for video subsystem...
Date: Fri, 05 May 2006 00:27:38 +0200	[thread overview]
Message-ID: <8764kla0it.fsf@night.trouble.net> (raw)
In-Reply-To: <4407474E.6060708@nic.fi> (Vesa Jääskeläinen's message of "Thu, 02 Mar 2006 21:28:14 +0200")

Vesa Jääskeläinen <chaac@nic.fi> writes:

> Here is the newest modifications to video subsystem.

Hi Vesa.  What a suitable name :)

Sorry for the delay, and lack of earlier comments, but I've been out
of the GRUB loop for a while.  But I have a few comments on the video
subsystem;

Correct me if I am wrong here, but what you call "render target" seems
to be what other video systems call "surface" or "drawable".  

Why use the concept of a "active" render target?  Why not instead let
all functions that operate on the active render target take a pointer
to a specific render target?  Poking through your patch, it seems that
there a lot of the following (forgive my pseudo-code)

   grub_video_set_active_render_target (target);
   // .. fill it with something ..
   grub_video_fill_rect (color, 0, 0, width, height);

   grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY);
   grub_video_blit_render_target (target, 0, 0, 0, 0, width, height);
   
I would feel more comfortable with the following workflow:

   grub_video_fill_rect (target, color, 0, 0, width, height);
   grub_video_blit_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY,
                                  target, 0, 0, 0, 0, width, height);

Also, I think it is important the user can get hold of a pointer to
the render targets data, and an exact pixel format, to do private
rendering.  It would be hard to make a perfect gradient using fill_rect.

I'm not sure the concept of "viewports" are needed at all; instead let
the 'application' (e.g, the terminal) render into a render target, and
blit that to the screen at the desired position.  To minimize memory,
the videport-render target can be a sub-render target of the main
render target (ie, they share the same buffer) unless the user wants
any fancy stuff like a background picture.

Thanks,
Johan




  parent reply	other threads:[~2006-05-04 22:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-02 19:28 New patch for video subsystem Vesa Jääskeläinen
2006-03-03 11:49 ` Marco Gerards
2006-03-03 15:23   ` Vesa Jääskeläinen
2006-03-05 22:25     ` Yoshinori K. Okuji
2006-03-06 19:56       ` Vesa Jääskeläinen
2006-03-09 20:43         ` Vesa Jääskeläinen
2006-03-10 12:21           ` Vesa Jääskeläinen
2006-03-12 14:49     ` Marco Gerards
2006-03-12 21:23       ` Vesa Jääskeläinen
2006-03-14 17:09         ` Vesa Jääskeläinen
2006-03-12 14:50     ` Marco Gerards
2006-05-04 22:27 ` Johan Rydberg [this message]
2006-05-05  8:21   ` Vesa Jääskeläinen
2006-05-05 11:06     ` Johan Rydberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8764kla0it.fsf@night.trouble.net \
    --to=jrydberg@night.trouble.net \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.