[fpc-devel] graph module

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Mar 9 16:36:40 CET 2007


On 9 mrt 2007, at 16:26, Evgeniy Ivanov wrote:

> On Fri, 09 Mar 2007 18:08:35 +0300, Jonas Maebe  
> <jonas.maebe at elis.ugent.be> wrote:
>
>> The graph unit is pretty generic in this respect. You indeed only  
>> need to implement putpixel, getpixel, graphics mode detection,  
>> setting a graphic mode, setting and getting colour palette entries  
>> for indexed modes, and closing down the graphic system again. But  
>> it's perfectly possible to also intercept line, elipse, rectangle  
>> etc and to implement them directly in the "driver".
>
> So, I may implement only putpixel and etc, but then if I wish I may  
> implement line and othe stuff inside my part of code (or somewhere)?

Yes, inside your code.

>> It's the way the whole graphics unit is designed to work. Note  
>> that "driver" is just used in the figurative sense here. In  
>> practice, you simply write your code and set some procedure  
>> variables inside the graph unit so it calls your code.
>
> So will be there different ways of using different back-ends  
> directly from graph unit like to have some variables like sdlgraph=1?

No, this is done by creating differently named graph units. All  
common graph unit code is in some include files, and to create a new  
graph unit for a different platform/library, you create a new unit  
with code needed for this platform library, and which includes all  
those generic include files.

See e.g. the graph.pp and ggigraph.pp files at
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/

The include files are in
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/

>> That's true, and it's the case for most libraries out there.  
>> Converting all libraries from C to Pascal rather than the headers  
>> would be a huge and never-ending duplication of effort. There's  
>> nothing wrong with using Pascal interfaces for libraries which are  
>> written in another language.
>
> So if I will implement it in C with pascal headers it have a chance  
> to be a part of freepascal?

Very little. We do this to reuse work done and maintained by others,  
not for new code which we support and maintain (since we ourselves  
are Pascal programmers, not C programmers).


Jonas



More information about the fpc-devel mailing list