Re: New patch for video subsystem...

[Johan Rydberg]

Vesa Jääskeläinen <address@hidden> writes:

> But the idea here was to make it easier to make function that operates
> on different render targets without knowing about it. eg:
>
> set_target a
> call common_func
> set target b
> call common_func
> set target c
>
> With your proposal this would require to pass this render target pointer
> all around and would make video function calls longer.

I do not see a problem with that.  The overhead for passing of an
extra argument is probably less than the overhead of the function
calls (esp since set_active_render_target is an indirect call)

> There is also another problem in your proposal. What happens if video
> driver get's changed and you still have pointers to render targets (or
> to raw memory)?

Possibly the same thing as with the current method; I do not see how
this would make things different?

>> 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.
>
> That might not be possible on all architectures. That's the reason there
> is a bitmap support (which I am working on currently). Bitmaps are
> located on host memory so they can be modified.

I'm not sure "bitmap" is a good word here; maybe "image" would be better.

> Render targets can be located on host memory or on video memory
> depending on arch. If they are located on video memory then there is
> only need to have video-video blit functionality and some archs might
> even provide hardware accelerated helper functions.

If the architecture does not support direct access to the video
memory, it just falls back on returning a render target with
malloc()ed memory.

> One idea of the render targets are that they hide the real bitmap data
> format. So one could make a 24 bit RGB picture and then just blit it to
> render target and underlying video driver would convert it to correct
> format. This frees API user from thinking all possible formats and can
> concentrate to make one working implementation.

Iter-format blits can of course also be supported if you have direct
access to the render target pixel data.

> If one needs to modify render target on all platforms there should be
> support to direct access to memory or ability to read contents of frame
> buffer to host memory and then write it back or requirement to store
> data on host memory and then do blit from there to video memory, but
> that is a bit costy on performance.

I do not see why that should be needed.

Have you looked at for example DirectFB's API?  Even through their
coding style is fucked up, the overall design of the API is quite
nice.

I'm just afraid that we will see the exact same thing that happened to
legacy GRUB; a lot of distribution vendors hack up something of their
own.  Therefor it is important that we get this right.

~j