Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59186 > unrolled thread

chosing "small 2d graphics library" interface

Back to article view | Back to comp.lang.c

Contents

  chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-28 18:43 -0700
    Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 02:59 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 03:51 -0700
        Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 12:03 +0100
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 05:00 -0700
            Re: chosing "small 2d graphics library"  interface gof@somewhere.invalid (Gof) - 2015-04-01 08:02 +0000
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-01 09:40 +0100
                Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 04:04 -0700
        Re: chosing "small 2d graphics library"  interface Nobody <nobody@nowhere.invalid> - 2015-03-29 12:50 +0100
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 05:08 -0700
      Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 09:33 -0400
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:00 -0700
          Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 10:38 -0400
            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:43 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:24 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:32 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 05:00 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-01 07:25 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 07:36 -0700
        Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-03-29 14:33 -0400
          Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 12:36 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-03-29 13:01 -0700
    chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 04:12 -0700
      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 04:56 -0700
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:10 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:31 -0700
          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:40 -0700
      Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 13:32 +0100
        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 05:50 -0700
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 14:01 +0100
            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 06:37 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 14:58 +0100
                Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-02 15:11 +0100
                  Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 15:18 +0100
                    Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:21 -0700
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:34 -0700
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:47 -0700
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:45 -0700
                        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:57 -0700
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 10:15 -0700
                          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:34 +0100
                            Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:35 +0100
                      Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 17:45 +0100
                        Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 10:12 -0700
                          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 18:28 +0100
                          Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 01:06 +0100
                      Re: chosing "small 2d graphics library"  interface luser droog <luser.droog@gmail.com> - 2015-04-02 17:05 -0700
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 07:51 -0700
                    Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 15:56 +0100
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 08:14 -0700
                        Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 16:25 +0100
                          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 08:45 -0700
                            Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 17:00 +0100
                              Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 13:03 -0700
                                Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-05 14:25 -0700
                            Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 09:06 -0700
                              Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-02 18:22 +0200
                                Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-02 18:40 +0200
                                  Re: chosing "small 2d graphics library"  interface Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:20 -0500
                                Re: chosing "small 2d graphics library"  interface Rosario19 <Ros@invalid.invalid> - 2015-04-04 10:35 +0200
                                  Re: chosing "small 2d graphics library"  interface CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-04 09:53 -0700
                          Re: chosing "small 2d graphics library" interface Noob <root@127.0.0.1> - 2015-04-03 14:27 +0200
                            Re: chosing "small 2d graphics library" interface fir <profesor.fir@gmail.com> - 2015-04-03 05:38 -0700
                Re: chosing "small 2d graphics library"  interface Jeff Higgins <jeff@invalid.invalid> - 2015-04-02 19:23 -0400
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-02 23:46 -0700
        Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 08:03 -0700
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-02 16:14 +0100
            Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 12:42 -0700
            Re: chosing "small 2d graphics library"  interface CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-03 14:27 -0700
              Re: chosing "small 2d graphics library"  interface Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-03 14:50 -0700
        Re: chosing "small 2d graphics library"  interface Keith Thompson <kst-u@mib.org> - 2015-04-02 10:47 -0700
        Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-02 20:09 +0100
          Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 06:02 +0100
            Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 11:40 +0100
              Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 03:52 -0700
                Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 12:05 +0100
                  Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 04:36 -0700
                    Re: chosing "small 2d graphics library"  interface Bartc <bc@freeuk.com> - 2015-04-03 13:28 +0100
                      Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 06:04 -0700
                        Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 07:28 -0700
                          Re: chosing "small 2d graphics library"  interface fir <profesor.fir@gmail.com> - 2015-04-03 12:43 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-03 12:57 +0100
        Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 22:25 -0700
          Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 22:34 -0700
            Re: chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-03 23:09 -0700
              Re: chosing "small 2d graphics library"  interface Richard Heathfield <rjh@cpax.org.uk> - 2015-04-04 09:23 +0100
      chosing "small 2d graphics library"  interface asetofsymbols@gmail.com - 2015-04-02 07:26 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#59186 — chosing "small 2d graphics library" interface

Im not sure if this question qill find 
good answers here but imo problem is 
quite important (also interesting)

I got something like that, small 2d per 
pixel library on my own but the interface 
is a bit mess (not hard mess but i would 
like (ewentually) to get it really clean
and tidy ;-) (im blinking becouse in my case 
it may be hard, but at least rethinking the 
interface is not bad)

I need ExACT c intarface (small header)
some questions to consider

- should i make tlis library .lib or .dll,
maybe source (if source should I put it in one file or more?)

- should i make this library biger or smaller?
I think smaller is beter, though it is not really
clen if watching carefully, fir example if 
i care about optimisation then i need like to provide more versions of routines) [such liberery is form its nature rather small do not need 
vary many api calls, it seem that it should 
be forexample between 10 to 50 functions 
exposed, draw line, set pixel, ew drav bezier
draw sprite etc

- what should i put here (what functions ) to make it small but complete ?

- if i make variants for functions (for example
draw line with antialiasing and without) should i make separate function calls of parametrise the one?

- what style of function names should i exactly chose (this is most iportant question)
[ciould someone maybe wrote down the complete exact header examle?]

- such library is a set of functions operating (writing to) a 2 dimensional pixel buffer (of size SIZE_X, SIZE_Y) i am not totally convinced how i should use this buffer, should it be
encompased in library or should it be on the client code side and should i pass the pointer
(and sizes) in each api call
(efficiency is important so if i should pass
those 3 values BUFF, SIZE_X, SIZE_Y to each 
draw pixel, drawline it would be probably a 
waste, so what options do i have?


  

[toc] | [next] | [standalone]

#59193

On Sunday, March 29, 2015 at 2:43:53 AM UTC+1, fir wrote:
> Im not sure if this question qill find 
> good answers here but imo problem is 
> quite important (also interesting)
> 
> I got something like that, small 2d per 
> pixel library on my own but the interface 
> is a bit mess (not hard mess but i would 
> like (ewentually) to get it really clean
> and tidy ;-) (im blinking becouse in my case 
> it may be hard, but at least rethinking the 
> interface is not bad)
> 
> I need ExACT c intarface (small header)
> some questions to consider
> 
> - should i make tlis library .lib or .dll,
> maybe source (if source should I put it in one file or more?)
> 
> - should i make this library biger or smaller?
> I think smaller is beter, though it is not really
> clen if watching carefully, fir example if 
> i care about optimisation then i need like to provide more versions of routines) [such liberery is form its nature rather small do not need 
> vary many api calls, it seem that it should 
> be forexample between 10 to 50 functions 
> exposed, draw line, set pixel, ew drav bezier
> draw sprite etc
> 
> - what should i put here (what functions ) to make it small but complete ?
> 
> - if i make variants for functions (for example
> draw line with antialiasing and without) should i make separate function calls of parametrise the one?
> 
> - what style of function names should i exactly chose (this is most iportant question)
> [ciould someone maybe wrote down the complete exact header examle?]
> 
> - such library is a set of functions operating (writing to) a 2 dimensional pixel buffer (of size SIZE_X, SIZE_Y) i am not totally convinced how i should use this buffer, should it be
> encompased in library or should it be on the client code side and should i pass the pointer
> (and sizes) in each api call
> (efficiency is important so if i should pass
> those 3 values BUFF, SIZE_X, SIZE_Y to each 
> draw pixel, drawline it would be probably a 
> waste, so what options do i have?
>
I'd pass an rgba buffer, width and height.

An IMAGE structure is just a nuisance. Calling code has to set up the image, then convert
back to its own essentially similar image structure. Defining point strutters is the same
problem as defining bool. Before bool was standardised, I used to have the saying
"Bool breaks libraries".  

[toc] | [prev] | [next] | [standalone]

#59194

W dniu niedziela, 29 marca 2015 11:59:59 UTC+2 użytkownik Malcolm McLean napisał:
> >
> I'd pass an rgba buffer, width and height.
> 
> An IMAGE structure is just a nuisance. Calling code has to set up the image, then convert
> back to its own essentially similar image structure. Defining point strutters is the same
> problem as defining bool. Before bool was standardised, I used to have the saying
> "Bool breaks libraries".

but how to pas and on which side (user or library) hold it?

as agrumant thru stack to every api call?

(for me iw makig .lib the most 'viable' option
seem to make this as external variables with static-global acces probably on the library side

//lib.c

int BUFF_SIZE_X = 100;
int BUFF_SIZE_Y = 100;
unsigned BUFF = NULL;

void setup_buffer()
{ 
  BUFF = (unsigned*) realloc(
        BUFF, BUFF_SIZE_X *BUFF_SIZE_Y *4 );

}

void resize_buffer(int new_x, int new_y)
{
 BUFF_SIZE_X = new_x;
 BUFF_SIZE_Y = new_y;

 setup_buffer();
}
 
something like that seem to me best option (code is not important, i mean i need raw and
not slowed down raw acces (like "BUFF[y*BUFF_SIZE_X + x] = color" ) to this pixelbuffer data form both library routines, and user code area

(some improvements here? better naming or tricks?)

i could eventually try to make BUFF not a pointer but a fully static adress but im not sure if this is at all any difference and if compiler will treat it differently (?)

does maybe someone know if i will wrap such
code above in dll will i get slowdowns on 
acces to  BUFF[y*BUFF_SIZE_X + x] = color
form the user code or no?

[toc] | [prev] | [next] | [standalone]

#59195

On 29/03/15 11:51, fir wrote:

<snip>

> int BUFF_SIZE_X = 100;
> int BUFF_SIZE_Y = 100;
> unsigned BUFF = NULL;
>
> void setup_buffer()
> {
>    BUFF = (unsigned*) realloc(
>          BUFF, BUFF_SIZE_X *BUFF_SIZE_Y *4 );

Your cast is unnecessary. By adding it, however, you may be preventing 
your compiler from diagnosing the use of realloc without a prototype in 
scope (you forgot to #include <stdlib.h>).

If the call fails for any reason, realloc will overwrite BUFF with NULL, 
meaning that not only have you failed to resize the image buffer but 
also you've overwritten the buffer you already had. Using a temporary 
pointer allows you to step around this problem:

void *p = realloc(BUFF, BUFF_SIZE_X * BUFF_SIZE_Y * 4);
if(p != NULL)
{
   BUFF = p;
}

On a design note, you are restricting yourself to a single buffer and a 
single image size. That may not be the best of choices.

> something like that seem to me best option

Seldom have I seen so many poor design choices concentrated within so 
few lines of code.

> (code is not important, i mean i need raw and
> not slowed down raw acces

Step 1: make it easy to read and easy to maintain
Step 2: make it right (but keep it readable)
Step 3: make it fast (but keep it right and readable)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59197

W dniu niedziela, 29 marca 2015 13:03:43 UTC+2 użytkownik Richard Heathfield napisał:
> On 29/03/15 11:51, fir wrote:
> 
> <snip>
> 
> > int BUFF_SIZE_X = 100;
> > int BUFF_SIZE_Y = 100;
> > unsigned BUFF = NULL;
> >
> > void setup_buffer()
> > {
> >    BUFF = (unsigned*) realloc(
> >          BUFF, BUFF_SIZE_X *BUFF_SIZE_Y *4 );
> 
> Your cast is unnecessary. By adding it, however, you may be preventing 
> your compiler from diagnosing the use of realloc without a prototype in 
> scope (you forgot to #include <stdlib.h>).
> 
> If the call fails for any reason, realloc will overwrite BUFF with NULL, 
> meaning that not only have you failed to resize the image buffer but 
> also you've overwritten the buffer you already had. Using a temporary 
> pointer allows you to step around this problem:
> 
> void *p = realloc(BUFF, BUFF_SIZE_X * BUFF_SIZE_Y * 4);
> if(p != NULL)
> {
>    BUFF = p;
> }
> 
> On a design note, you are restricting yourself to a single buffer and a 
> single image size. That may not be the best of choices.
> 
> > something like that seem to me best option
> 
> Seldom have I seen so many poor design choices concentrated within so 
> few lines of code.
> 
Seldom i see such bullshitter - got a meaningfull answer, answer my questions
instead of deadly weak blalbling on your weak tunelled and demented delusions im not interested to read - I clearly see that you in your demention try to build some visions but this is a whole demential small bullshit
of yr, zero valuable answer here


> > (code is not important, i mean i need raw and
> > not slowed down raw acces
> 
> Step 1: make it easy to read and easy to maintain
> Step 2: make it right (but keep it readable)
> Step 3: make it fast (but keep it right and readable)
> 
deadly weak, get off

> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59379

fir <profesor.fir@gmail.com> wrote:

>> Step 1: make it easy to read and easy to maintain
>> Step 2: make it right (but keep it readable)
>> Step 3: make it fast (but keep it right and readable)
> 
> deadly weak, get off

And that's fir in all his glory.

I wonder why you still answer him...

AW

[toc] | [prev] | [next] | [standalone]

#59381

On 01/04/15 09:02, Gof wrote:
> fir <profesor.fir@gmail.com> wrote:
>
>>> Step 1: make it easy to read and easy to maintain
>>> Step 2: make it right (but keep it readable)
>>> Step 3: make it fast (but keep it right and readable)
>>
>> deadly weak, get off
>
> And that's fir in all his glory.
>
> I wonder why you still answer him...

I suppose it's the triumph of hope over experience. But yes, my patience 
is wearing a little thin.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59388

W dniu środa, 1 kwietnia 2015 10:40:27 UTC+2 użytkownik Richard Heathfield napisał:
> 
> I suppose it's the triumph of hope over experience. But yes, my patience 
> is wearing a little thin.
> 
I suppose you mistake "commonistic bullshit stock" (boring dementaial and at all harmfull) with the things "i am talking about"

[toc] | [prev] | [next] | [standalone]

#59196

On Sun, 29 Mar 2015 03:51:34 -0700, fir wrote:

> does maybe someone know if i will wrap such
> code above in dll will i get slowdowns on 
> acces to  BUFF[y*BUFF_SIZE_X + x] = color
> form the user code or no?

If you wrap the above in a set_pixel(x,y,color) function which you then
call in a loop, it's likely to have significantly worse performance than
using a macro or an inline function.

Also: I suggest allowing for a stride (offset between rows) which isn't
necessarily the same as width * bytes_per_pixel. Doing so allows you to
treat any rectangular subregion of an image as an image.

Personally, I'd define a structure for the image parameters, rather than
passing them as separate arguments.

[toc] | [prev] | [next] | [standalone]

#59198

W dniu niedziela, 29 marca 2015 13:50:54 UTC+2 użytkownik Nobody napisał:
> On Sun, 29 Mar 2015 03:51:34 -0700, fir wrote:
> 
> > does maybe someone know if i will wrap such
> > code above in dll will i get slowdowns on 
> > acces to  BUFF[y*BUFF_SIZE_X + x] = color
> > form the user code or no?
> 
> If you wrap the above in a set_pixel(x,y,color) function which you then
> call in a loop, it's likely to have significantly worse performance than
> using a macro or an inline function.
> 

> Also: I suggest allowing for a stride (offset between rows) which isn't
> necessarily the same as width * bytes_per_pixel. Doing so allows you to
> treat any rectangular subregion of an image as an image.
> 
stride is separate problem, (wonder if should do it only right down margin or also left up if so?)
could be usable for processing edge regions
but also comlicates code a bit (and thinking of this pixel area), i would have to manage it at resizes etc - so im not sure

(would like if someone would answer on the questions i explicitelt stated is most interesting imo, (though remarks are welcome))

> Personally, I'd define a structure for the image parameters, rather than
> passing them as separate arguments.

[toc] | [prev] | [next] | [standalone]

#59199

On 03/29/2015 05:59 AM, Malcolm McLean wrote:
> On Sunday, March 29, 2015 at 2:43:53 AM UTC+1, fir wrote:
>> Im not sure if this question qill find
>> good answers here but imo problem is
>> quite important (also interesting)
>>
>> I got something like that, small 2d per
>> pixel library on my own but the interface
>> is a bit mess (not hard mess but i would
>> like (ewentually) to get it really clean
>> and tidy ;-) (im blinking becouse in my case
>> it may be hard, but at least rethinking the
>> interface is not bad)
>>
>> I need ExACT c intarface (small header)
>> some questions to consider
>>
>> - should i make tlis library .lib or .dll,
>> maybe source (if source should I put it in one file or more?)
>>
>> - should i make this library biger or smaller?
>> I think smaller is beter, though it is not really
>> clen if watching carefully, fir example if
>> i care about optimisation then i need like to provide more versions of routines) [such liberery is form its nature rather small do not need
>> vary many api calls, it seem that it should
>> be forexample between 10 to 50 functions
>> exposed, draw line, set pixel, ew drav bezier
>> draw sprite etc
>>
>> - what should i put here (what functions ) to make it small but complete ?
>>
>> - if i make variants for functions (for example
>> draw line with antialiasing and without) should i make separate function calls of parametrise the one?
>>
>> - what style of function names should i exactly chose (this is most iportant question)
>> [ciould someone maybe wrote down the complete exact header examle?]
>>
>> - such library is a set of functions operating (writing to) a 2 dimensional pixel buffer (of size SIZE_X, SIZE_Y) i am not totally convinced how i should use this buffer, should it be
>> encompased in library or should it be on the client code side and should i pass the pointer
>> (and sizes) in each api call
>> (efficiency is important so if i should pass
>> those 3 values BUFF, SIZE_X, SIZE_Y to each
>> draw pixel, drawline it would be probably a
>> waste, so what options do i have?
>>
> I'd pass an rgba buffer, width and height.
>
> An IMAGE structure is just a nuisance. Calling code has to set up the image, then convert
> back to its own essentially similar image structure. Defining point strutters is the same
> problem as defining bool. Before bool was standardised, I used to have the saying
> "Bool breaks libraries".
>
I'm curious what the experts think of what
the Leptonica implementation has to offer.

I'm using it in a couple of applications and
it has so far been fast enough and easy to use.
But I'm not using it for interactive drawing
as fir seems hoping for.(I may be wrong here)

Basic file defining image and image-related structs
<http://tpgit.github.io/Leptonica/pix_8h_source.html>

Implements Pix (image) class - the fundamental one for this library.
<http://tpgit.github.io/Leptonica/pix1_8c_source.html>

Pixel poking of image, pad and border pixels.
<http://tpgit.github.io/Leptonica/pix2_8c_source.html>

Masking and logical ops, counting, mirrored tiling.
<http://tpgit.github.io/Leptonica/pix3_8c_source.html>

Histograms, fg/bg estimation, rectangle extraction.
<http://tpgit.github.io/Leptonica/pix4_8c_source.html>

[toc] | [prev] | [next] | [standalone]

#59200

W dniu niedziela, 29 marca 2015 15:35:15 UTC+2 użytkownik Jeff Higgins napisał:
> >
> I'm curious what the experts think of what
> the Leptonica implementation has to offer.
> 
> I'm using it in a couple of applications and
> it has so far been fast enough and easy to use.
> But I'm not using it for interactive drawing
> as fir seems hoping for.(I may be wrong here)
> 

Its good for realtime* just significantly (30x ?) slower i am using it for tinkering and prototyping ..

(but it is not a subject of this topic, the 
subjest of this topic is interface/ lib
 header (I got implementation already (most of it) but i got no interface) (if someone has some thought, even not perfect and subjective i would like to hear)








> Basic file defining image and image-related structs
> <http://tpgit.github.io/Leptonica/pix_8h_source.html>
> 
> Implements Pix (image) class - the fundamental one for this library.
> <http://tpgit.github.io/Leptonica/pix1_8c_source.html>
> 
> Pixel poking of image, pad and border pixels.
> <http://tpgit.github.io/Leptonica/pix2_8c_source.html>
> 
> Masking and logical ops, counting, mirrored tiling.
> <http://tpgit.github.io/Leptonica/pix3_8c_source.html>
> 
> Histograms, fg/bg estimation, rectangle extraction.
> <http://tpgit.github.io/Leptonica/pix4_8c_source.html>

[toc] | [prev] | [next] | [standalone]

#59204

On 03/29/2015 10:00 AM, fir wrote:
> W dniu niedziela, 29 marca 2015 15:35:15 UTC+2 użytkownik Jeff Higgins napisał:
>>>
>> I'm curious what the experts think of what
>> the Leptonica implementation has to offer.
>>
>> I'm using it in a couple of applications and
>> it has so far been fast enough and easy to use.
>> But I'm not using it for interactive drawing
>> as fir seems hoping for.(I may be wrong here)
>>
>
> Its good for realtime* just significantly (30x ?) slower i am using it for tinkering and prototyping ..
>
> (but it is not a subject of this topic, the
> subjest of this topic is interface/ lib
>   header (I got implementation already (most of it) but i got no interface) (if someone has some thought, even not perfect and subjective i would like to hear)
>
Ah, sorry, I didn't intend to hijack your thread.
Your paragraph which began with:
"- such library is a set of functions operating (writing to) a 2 
dimensional pixel buffer",
and then Malcolm McLean's comment concerning
"An IMAGE structure is just a nuisance."
is what got me started.
[snip off subject links]

[toc] | [prev] | [next] | [standalone]

#59205

W dniu niedziela, 29 marca 2015 16:40:27 UTC+2 użytkownik Jeff Higgins napisał:
> On 03/29/2015 10:00 AM, fir wrote:
> > W dniu niedziela, 29 marca 2015 15:35:15 UTC+2 użytkownik Jeff Higgins napisał:
> >>>
> >> I'm curious what the experts think of what
> >> the Leptonica implementation has to offer.
> >>
> >> I'm using it in a couple of applications and
> >> it has so far been fast enough and easy to use.
> >> But I'm not using it for interactive drawing
> >> as fir seems hoping for.(I may be wrong here)
> >>
> >
> > Its good for realtime* just significantly (30x ?) slower i am using it for tinkering and prototyping ..
> >
> > (but it is not a subject of this topic, the
> > subjest of this topic is interface/ lib
> >   header (I got implementation already (most of it) but i got no interface) (if someone has some thought, even not perfect and subjective i would like to hear)
> >
> Ah, sorry, I didn't intend to hijack your thread.
> Your paragraph which began with:
> "- such library is a set of functions operating (writing to) a 2 
> dimensional pixel buffer",
> and then Malcolm McLean's comment concerning
> "An IMAGE structure is just a nuisance."
> is what got me started.
> [snip off subject links]

not a problem, got nota problem with that ;-)
only wanted to specify what answer and advices /thoughts im searching for if someone has to say something 

[toc] | [prev] | [next] | [standalone]

#59201

W dniu niedziela, 29 marca 2015 15:35:15 UTC+2 użytkownik Jeff Higgins napisał:
> Basic file defining image and image-related structs
> <http://tpgit.github.io/Leptonica/pix_8h_source.html>
> 
> Implements Pix (image) class - the fundamental one for this library.
> <http://tpgit.github.io/Leptonica/pix1_8c_source.html>
> 
> Pixel poking of image, pad and border pixels.
> <http://tpgit.github.io/Leptonica/pix2_8c_source.html>
> 
> Masking and logical ops, counting, mirrored tiling.
> <http://tpgit.github.io/Leptonica/pix3_8c_source.html>
> 
> Histograms, fg/bg estimation, rectangle extraction.
> <http://tpgit.github.io/Leptonica/pix4_8c_source.html>

to much complex mine lib is simple: draw pixel, line, circle, trangle, rectangle, besier, fill circle, fill triangle, fill
rectangle, (should maybe need something like 
line path, filled line path, filled bezier path though not implemented) and bitmap 
sprite (scaled and rotated) nad that would be about all (aa not yet implemented, blending of colors not yet implemented, other also not implemented)

need to decide what i really need,and how interface it,.. some hints?

Im not even sure if api names should be 
draw_line or DrawLine, or tu use SetPixel, putPixel or DrawPixel, may sound fun
but i find such details important and such decisions important

[toc] | [prev] | [next] | [standalone]

#59202

W dniu niedziela, 29 marca 2015 16:24:22 UTC+2 użytkownik fir napisał:
> 
> need to decide what i really need,and how interface it,.. some hints?
> 
PS/add

(well, wathing my own description it comes to mint that i can put down just 

Draw... //all i mentioned header

as a first draft, then think if i can improve it.. will do that a bit later)

[toc] | [prev] | [next] | [standalone]

#59395

ps if someone would like to see how my small library works at work, here may see 

https://www.dropbox.com/s/3nm8q09fesoksxa/v21.zip?dl=0

feedback would be appreciated, how fine it 
looks (imo fine 8/10) and how fast, the number
in right down is miliseccond

some test welcome

[toc] | [prev] | [next] | [standalone]

#59400

W dniu środa, 1 kwietnia 2015 14:01:16 UTC+2 użytkownik fir napisał:
> ps if someone would like to see how my small library works at work, here may see 
> 
> https://www.dropbox.com/s/3nm8q09fesoksxa/v21.zip?dl=0
> 
> feedback would be appreciated, how fine it 
> looks (imo fine 8/10) and how fast, the number
> in right down is miliseccond
> 
> some test welcome

whattdoya think?

[toc] | [prev] | [next] | [standalone]

#59203

W dniu niedziela, 29 marca 2015 11:59:59 UTC+2 użytkownik Malcolm McLean napisał:
> 
> An IMAGE structure is just a nuisance. 

i agree with that, image struct it seem good in theory 9everybody seem agree in that ) but in practise it gives some level of opaquesness and burdensomness and is not such good

[toc] | [prev] | [next] | [standalone]

#59229

On 03/29/2015 10:36 AM, fir wrote:
> W dniu niedziela, 29 marca 2015 11:59:59 UTC+2 użytkownik Malcolm McLean napisał:
>>
>> An IMAGE structure is just a nuisance.
>
> i agree with that, image struct it seem good in theory 9everybody seem agree in that ) but in practise it gives some level of opaquesness and burdensomness and is not such good
>
In an adjacent thread I mentioned the Leptonica PIX structure.
Not being even close to an expert C language programmer,
but wishing to learn, I wonder if this PIX structure is an
example of an (IMAGE | image) + (structure | struct) that
you and Malcolm McLean are discussing?

If so, I wonder what makes its use burdensome and a nuisance?
If not, I'll apologize now for the interruption.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web