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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#59478

On 02/04/15 18:15, Malcolm McLean wrote:
> On Thursday, April 2, 2015 at 5:45:23 PM UTC+1, fir wrote:
>> W dniu czwartek, 2 kwietnia 2015 18:21:34 UTC+2 użytkownik Malcolm McLean napisał:
>> > Brasenham's
>>
>> for me bressenham is not so fast,
>> i disvcovered faster one, thought
>> i yet not implemented it (for leaziness)
>>
> Wu's line-drawing algorithm is a bit faster.


An implementation of Wu's algorithm in C can be found in Graphics Gems 
(Glassner 1998) pp868-689.

-- 
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]

#59479

On 02/04/15 18:34, Richard Heathfield wrote:
> On 02/04/15 18:15, Malcolm McLean wrote:
>> On Thursday, April 2, 2015 at 5:45:23 PM UTC+1, fir wrote:
>>> W dniu czwartek, 2 kwietnia 2015 18:21:34 UTC+2 użytkownik Malcolm McLean napisał:
>>> > Brasenham's
>>>
>>> for me bressenham is not so fast,
>>> i disvcovered faster one, thought
>>> i yet not implemented it (for leaziness)
>>>
>> Wu's line-drawing algorithm is a bit faster.
>
>
> An implementation of Wu's algorithm in C can be found in Graphics Gems
> (Glassner 1998) pp868-689.


686-689 (furrfu)

-- 
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]

#59470

On 02/04/15 17:21, Malcolm McLean wrote:
> On Thursday, April 2, 2015 at 3:18:51 PM UTC+1, Richard Heathfield wrote:
>>
>> By the way, I anticipate at least a certain amount of intelligent
>> disagreement over my choice of memory allocation strategy, and I can
>> understand that. There's More Than One Way To Do It, and I like my way,
>> and it works, but I realise that there are advantages to doing it in
>> other ways. The OP might benefit from an "fewer mallocs" advocate's
>> exposition of those advantages. (I could probably do it myself, but my
>> heart wouldn't really be in it.)
>>
> Most existing libraries write to flat buffers.

First, I'll tell you why that's a bad idea. Then I'll tell you why it's 
a good idea. :-)

It's a bad idea because it makes the task of visualising the data 
structure more difficult, which means that you're more likely to 
introduce bugs when writing functions that address the buffer. Data 
structures that are easy to visualise have significant benefits.

It's a good idea because (a) it's one malloc instead of dozens or 
hundreds or even, potentially, thousands; (b) you can address the whole 
buffer in one loop instead of two; (c) it makes blitting substantially 
simpler and faster, at least when you are dealing with entire rows 
(stride may help out here, of course); (d) if you really want a 
rectangle, it's easy enough to write interface code so that you can 
treat it like one, thus more or less negating the "bad idea" objection 
above.

So, all in all, that would seem to be a win-win-win-scoredraw for a flat 
buffer. Which fact makes me ponder whether I need to rewrite my own 
library to use flat buffers. (Answer: inertia!)


> An annoying thing about C is
> that sometime you want to access the buffer on a per-pixel basis, at other
> times on a per-channel basis, and you want to do that without making your
> buffer too complicated.

I don't quite get why that would be /particularly/ annoying in C, as 
opposed to some other language. Could you unpack that a little?

>> Also, if I were writing the article over, I'd probably have made more
>> (i.e. some!) use of the alpha channel in the SetColour function. My only
>> excuse is that I forgot. I might even have taken the time to demonstrate
>> Bresenham's line-drawing algorithm, and perhaps an ellipse plotting
>> function.
>>
> Alpha raises lots of issues. It means that you can't write twice to a pixel and
> assume that the second write is a no-op.

It wouldn't have occurred to me to write twice to the same pixel in the 
same operation. Is there an advantage to doing that?

> Also, a lot of systems pre-mulitply
> alpha for performance reasons. And you've got to decide whether your starting
> buffer is solid black, or total transparency.

Or solid some-other-colour, presumably?

> Brasenham's line drawing algorithm is one of those things which is useful for
> intermediate output, but not so useful for final graphics. Users like anti-
> aliased lines with nice joins, so in fact they are usually drawn as thin polygons.

Fair comment, although personally I like single-pixel lines, jaggies and 
all! Yes, of course I like anti-aliased lines too. I like to have the 
choice.

> But because of the join issue, you need to create an entire path, then submit
> it. But that creates issues for branching lines.

What do you mean by "the join issue"?

-- 
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]

#59473

On Thursday, April 2, 2015 at 5:45:38 PM UTC+1, Richard Heathfield wrote:
> 
> > An annoying thing about C is
> > that sometime you want to access the buffer on a per-pixel basis, at other
> > times on a per-channel basis, and you want to do that without making your
> > buffer too complicated.
> 
> I don't quite get why that would be /particularly/ annoying in C, as 
> opposed to some other language. Could you unpack that a little?
> 
You want to be able to do several things.
1) access each pixel in a  single indexing operation.
2) store a pixel in a  32 bit data register.
3) access the channels in a single indexing operation.
4) pass about raw binary data buffers to functions which don't have your
"Pixel" structure in scope.
5) constrain the image buffer to be in whole pixel alignment. 
6) pass the buffer to specialised hardware that might clear it in a fast
operation, lock it for display to the screen, or similar.

You can declare a struct pixel. But there's no good way of making sure that
it goes into registers for simple copying operations.Or you can declare the buffer
to be an array of uint32_ts, in which case getting the channels is messy
and you can have endianness problems. Or you can used unsigned char *buffers,
in which case the indexing is messy and on a  per-channel basis.
>
> It wouldn't have occurred to me to write twice to the same pixel in the 
> same operation. Is there an advantage to doing that?
>
It can make the code easier to write. If you're drawing a line with a joint in
it from A to B to C, it's a lot easier if you can write to B.x, B.y twice without
worrying that you'll get a double-opacity pixel.
>
> > But because of the join issue, you need to create an entire path, then submit
> > it. But that creates issues for branching lines.
> 
> What do you mean by "the join issue"?
> 
If we draw aline with a corner in it, we need to know if the join is bevelled,
mitred, capped, or if there isn't one and we actually want two rectangles
with a common mid-point at one of the short ends.

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

#59477

On 02/04/15 18:12, Malcolm McLean wrote:
> On Thursday, April 2, 2015 at 5:45:38 PM UTC+1, Richard Heathfield wrote:
>>
>> > An annoying thing about C is
>> > that sometime you want to access the buffer on a per-pixel basis, at other
>> > times on a per-channel basis, and you want to do that without making your
>> > buffer too complicated.
>>
>> I don't quite get why that would be /particularly/ annoying in C, as
>> opposed to some other language. Could you unpack that a little?
>>
> You want to be able to do several things.
> 1) access each pixel in a  single indexing operation.
> 2) store a pixel in a  32 bit data register.
> 3) access the channels in a single indexing operation.
> 4) pass about raw binary data buffers to functions which don't have your
> "Pixel" structure in scope.
> 5) constrain the image buffer to be in whole pixel alignment.
> 6) pass the buffer to specialised hardware that might clear it in a fast
> operation, lock it for display to the screen, or similar.

You seem to be addressing the drawbacks of a struct specifically for 
pixels, but I don't recall proposing one. Rather, I was proposing an 
at-least-32-bits unsigned integer (I use unsigned long int), which I 
think meets all your criteria listed above.


> You can declare a struct pixel. But there's no good way of making sure that
> it goes into registers for simple copying operations.Or you can declare the buffer
> to be an array of uint32_ts, in which case getting the channels is messy

Ah, here we are. Yes, that's how I do it, and yes, getting channel info 
is a little tedious, but a little macro-sugar works reasonably well.

> and you can have endianness problems.

I can see how that might be an issue when writing out to a file or 
reading in, but that would just be one of the things you'd have to deal 
with when performing file I/O, wouldn't it? A mild annoyance at worst. 
Or do you mean that your data might sometimes be shipped out to a GPU 
having different endianness from your CPU? I can see how that would be a 
proverbial pain, but does it really happen?

 > Or you can used unsigned char *buffers,
> in which case the indexing is messy and on a  per-channel basis.

Yes. I'm not convinced that unsigned char * is the way to go.

>> It wouldn't have occurred to me to write twice to the same pixel in the
>> same operation. Is there an advantage to doing that?
>>
> It can make the code easier to write. If you're drawing a line with a joint in
> it from A to B to C, it's a lot easier if you can write to B.x, B.y twice without
> worrying that you'll get a double-opacity pixel.

Okay, I can buy that. I'm not sure I'd write the code that way, but I do 
take the point.

>> > But because of the join issue, you need to create an entire path, then submit
>> > it. But that creates issues for branching lines.
>>
>> What do you mean by "the join issue"?
>>
> If we draw aline with a corner in it, we need to know if the join is bevelled,
> mitred, capped, or if there isn't one and we actually want two rectangles
> with a common mid-point at one of the short ends.

Presumably because the anti-aliasing is dependent on the surrounding 
pixel values.

-- 
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]

#59498

On 02/04/2015 18:12, Malcolm McLean wrote:
> On Thursday, April 2, 2015 at 5:45:38 PM UTC+1, Richard Heathfield wrote:

>> It wouldn't have occurred to me to write twice to the same pixel in the
>> same operation. Is there an advantage to doing that?
>>
> It can make the code easier to write. If you're drawing a line with a joint in
> it from A to B to C, it's a lot easier if you can write to B.x, B.y twice without
> worrying that you'll get a double-opacity pixel.

That depends on what you mean by an 'alpha' component and what you do 
with it.

(To me, alpha or transparency is something that is used when displaying 
this image over another or over a background. If the image display is 
updated when writing to it, then if a pixel is set to red with 50% 
transparency, then after updating it again, it'll still be red with with 
50% transparency.)

What can affect being able to write twice is the drawing mode in effect 
for RGB, eg. 'xor' mode, or anything that modifies the current pixel 
rather than replaces it, such as making it /more/ red. This can be a 
problem even without a transparency channel.

-- 
Bartc

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

#59497

On Thursday, April 2, 2015 at 11:21:34 AM UTC-5, Malcolm McLean wrote:
> On Thursday, April 2, 2015 at 3:18:51 PM UTC+1, Richard Heathfield wrote:
> >
> > By the way, I anticipate at least a certain amount of intelligent 
> > disagreement over my choice of memory allocation strategy, and I can 
> > understand that. There's More Than One Way To Do It, and I like my way, 
> > and it works, but I realise that there are advantages to doing it in 
> > other ways. The OP might benefit from an "fewer mallocs" advocate's 
> > exposition of those advantages. (I could probably do it myself, but my 
> > heart wouldn't really be in it.)
> >
> Most existing libraries write to flat buffers. An annoying thing about C is
> that sometime you want to access the buffer on a per-pixel basis, at other 
> times on a per-channel basis, and you want to do that without making your
> buffer too complicated.  

Echoing -mew and leary, I also thoroughly enjoyed Richard's
article which reminded me of my nostalgia for the nntp I never
knew in the last autumn before sept.

I have posted a copy of the original Warnock/Wyatt eands-xerox-
adobe image model in this thread: 
https://groups.google.com/d/topic/comp.lang.postscript/wrkPdGdw8cE/discussion

The pascal-like notation is actually Xerox's Mesa language,
which had some advanced features for specifying Modules of
code, so portions of the interface are pluggable, like hot-
loading dlls, but all built-in to the language, and transparent
to the implementation (!).

-- 
too many puns?

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

#59454

W dniu czwartek, 2 kwietnia 2015 16:11:20 UTC+2 użytkownik Bart napisał:

> But then fir often states such ludicrous things that it's actually funny.
> 
> fir - you should write a book. I think it would sell, but for the wrong 
> reasons.
> 

book on what?  making 2d libraries?

(that 'article' of r.h. was really
weak, i was making such implementations 
(as bressenham , clipping etc)
long time ago and i would discuss it to 
a bit more advanced points 

(i know not many 2d libs developers here but i wanted to discuss a design and design choices 
of the interface of c library, check out the lib design questions, they are still interesting) (maybe i will answer it myself as i am working and thinking a bit on this now)

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

#59455

On 02/04/15 15:51, fir wrote:
> W dniu czwartek, 2 kwietnia 2015 16:11:20 UTC+2 użytkownik Bart napisał:
>
>> But then fir often states such ludicrous things that it's actually funny.
>>
>> fir - you should write a book. I think it would sell, but for the wrong
>> reasons.
>>
>
> book on what?  making 2d libraries?

Any book, on any subject. He thinks it would be amusing to see an entire 
book written in your distinctive style.

> (that 'article' of r.h. was really
> weak,

So you say.

> i was making such implementations
> (as bressenham , clipping etc)
> long time ago and i would discuss it to
> a bit more advanced points

Go ahead and show us the code. I'd love to learn what you think "strong" 
code looks like.

-- 
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]

#59458

W dniu czwartek, 2 kwietnia 2015 16:56:28 UTC+2 użytkownik Richard Heathfield napisał:
> On 02/04/15 15:51, fir wrote:
> > W dniu czwartek, 2 kwietnia 2015 16:11:20 UTC+2 użytkownik Bart napisał:
> >
> >> But then fir often states such ludicrous things that it's actually funny.
> >>
> >> fir - you should write a book. I think it would sell, but for the wrong
> >> reasons.
> >>
> >
> > book on what?  making 2d libraries?
> 
> Any book, on any subject. He thinks it would be amusing to see an entire 
> book written in your distinctive style.
> 
> > (that 'article' of r.h. was really
> > weak,
> 
> So you say.
> 
> > i was making such implementations
> > (as bressenham , clipping etc)
> > long time ago and i would discuss it to
> > a bit more advanced points
> 
> Go ahead and show us the code. I'd love to learn what you think "strong" 
> code looks like.
> 
here it is a topic on lib 2d header, it is good oportunity for talking about code piece
 header is a code also, if some will post propositions i can post contrproposition or agree with that

you can also check exacutable example

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

(executable program is more important as i do not care much for form and often redesign or work in chaos so my code has not finite shape - thus i cannot show something that has not a form)

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

#59459

On 02/04/15 16:14, fir wrote:
> W dniu czwartek, 2 kwietnia 2015 16:56:28 UTC+2 użytkownik Richard Heathfield napisał:
>> On 02/04/15 15:51, fir wrote:

<snip>

>>
>> > i was making such implementations
>> > (as bressenham , clipping etc)
>> > long time ago and i would discuss it to
>> > a bit more advanced points
>>
>> Go ahead and show us the code. I'd love to learn what you think "strong"
>> code looks like.
>>
> here it is a topic on lib 2d header,

Where's the code?

> it is good oportunity for talking about code piece
>   header is a code also, if some will post propositions i can post contrproposition or agree with that
>
> you can also check exacutable example
>
> https://www.dropbox.com/s/3nm8q09fesoksxa/v21.zip?dl=0

No code there. Where's the code?

>
> (executable program is more important

No, the source code is far more important. We can use the source code to 
create an executable program if we care enough, but we can't extract the 
C source from the executable program, so we have no way to judge the 
quality of the code. Also, nobody here is going to be stupid enough to 
run an executable program posted on DropBox by a complete stranger.

> as i do not care much for form and often redesign or work in chaos so my code has not finite shape - thus i cannot show something that has not a form)

Ah, I see. You are of course under no obligation to show us any C code 
that you have written, whether it be for graphics or anything else. You 
are also completely free to criticise other people's work for being 
"weak" without actually pointing out any technical issues. And those who 
read your articles are equally free to draw their own conclusions from 
such behaviour.

-- 
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]

#59460

W dniu czwartek, 2 kwietnia 2015 17:25:27 UTC+2 użytkownik Richard Heathfield napisał:
> On 02/04/15 16:14, fir wrote:
> > W dniu czwartek, 2 kwietnia 2015 16:56:28 UTC+2 użytkownik Richard Heathfield napisał:
> >> On 02/04/15 15:51, fir wrote:
> 
> <snip>
> 
> >>
> >> > i was making such implementations
> >> > (as bressenham , clipping etc)
> >> > long time ago and i would discuss it to
> >> > a bit more advanced points
> >>
> >> Go ahead and show us the code. I'd love to learn what you think "strong"
> >> code looks like.
> >>
> > here it is a topic on lib 2d header,
> 
> Where's the code?
> 

I see you start playing simpleton again.. 

> > it is good oportunity for talking about code piece
> >   header is a code also, if some will post propositions i can post contrproposition or agree with that
> >
> > you can also check exacutable example
> >
> > https://www.dropbox.com/s/3nm8q09fesoksxa/v21.zip?dl=0
> 
> No code there. Where's the code?
> 
> >
> > (executable program is more important
> 
> No, the source code is far more important. We can use the source code to 
> create an executable program if we care enough, but we can't extract the 
> C source from the executable program, so we have no way to judge the 
> quality of the code. Also, nobody here is going to be stupid enough to 
> run an executable program posted on DropBox by a complete stranger.
> 
> > as i do not care much for form and often redesign or work in chaos so my code has not finite shape - thus i cannot show something that has not a form)
> 
> Ah, I see. You are of course under no obligation to show us any C code 
> that you have written, whether it be for graphics or anything else. You 
> are also completely free to criticise other people's work for being 
> "weak" without actually pointing out any technical issues. And those who 
> read your articles are equally free to draw their own conclusions from 
> such behaviour.
> 
ohh, here we go again, i very long time didnt saw sych stupid.. think it is enough for me..
I know you have hevy lacks of intelligence but i think you should at least try to obfuscate this.. and you are not so we have not a thing to talk .. i dont want any simpleton to waste my time .. keep out poor mister,

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

#59461

On 02/04/15 16:45, fir wrote:
> W dniu czwartek, 2 kwietnia 2015 17:25:27 UTC+2 użytkownik Richard Heathfield napisał:
>> On 02/04/15 16:14, fir wrote:
>> > W dniu czwartek, 2 kwietnia 2015 16:56:28 UTC+2 użytkownik Richard Heathfield napisał:
>> >> On 02/04/15 15:51, fir wrote:
>>
>> <snip>
>>
>> >>
>> >> > i was making such implementations
>> >> > (as bressenham , clipping etc)
>> >> > long time ago and i would discuss it to
>> >> > a bit more advanced points
>> >>
>> >> Go ahead and show us the code. I'd love to learn what you think "strong"
>> >> code looks like.
>> >>
>> > here it is a topic on lib 2d header,
>>
>> Where's the code?
>>
>
> I see you start playing simpleton again..

So no code, then. I didn't think so.

<snip>

-- 
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]

#59489

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/04/15 16:45, fir wrote:
>> W dniu czwartek, 2 kwietnia 2015 17:25:27 UTC+2 użytkownik Richard Heathfield napisał:
>>> On 02/04/15 16:14, fir wrote:
[...]
>>> > here it is a topic on lib 2d header,
>>>
>>> Where's the code?
>>
>> I see you start playing simpleton again..
>
> So no code, then. I didn't think so.
>
> <snip>

Is it time to stop feeding the troll yet?  (Or whatever fir is; I don't
particularly care whether he's deliberately trolling or not.)

By replying to him, you are triggering an increase in the number of
articles he posts here.  That is, IMHO, not a good thing.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#59659

W dniu czwartek, 2 kwietnia 2015 22:03:50 UTC+2 użytkownik Keith Thompson napisał:
> 
> Is it time to stop feeding the troll yet?  (Or whatever fir is; I don't
> particularly care whether he's deliberately trolling or not.)
> 

(frgot to comment that)

This above is extremally primitive and you keith tompson shameless insulter imo should 
feel very vivid shame playing such simpletoning 
of middle ages among the people im sure not at all so primitive  (of course i am quite avere 
youre a primitive ao you feel no guilty  but if
i will point it out  you may become to think on it and fortunately not so well integrated in your insulting aura 

i get used to usenet primitives insulters,
much to primitive for me so for me it is only minor distaste  - though maybe still worth noting a bit



> By replying to him, you are triggering an increase in the number of
> articles he posts here.  That is, IMHO, not a good thing.
> 

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

#59463

ps. as to executable this is pure winapi graphics app do not changes anything in system,
do not make any internet connection etc,
is not aany kind of malware
I am testing my system by antivir and do not detect i got any contagious virus here
(so as far as i can be sure 99.99% I think
it is not any kind of damege soft and can 
be just used)

afaik shoul also work in linus through wine emulator, or maybe in wirtual machine or something

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

#59465

On Thu, 2 Apr 2015 09:06:24 -0700 (PDT), fir wrote:

>ps. as to executable this is pure winapi graphics app do not changes anything in system,
>do not make any internet connection etc,
>is not aany kind of malware
>I am testing my system by antivir and do not detect i got any contagious virus here
>(so as far as i can be sure 99.99% I think
>it is not any kind of damege soft and can 
>be just used)
>
>afaik shoul also work in linus through wine emulator, or maybe in wirtual machine or something

i seen you speak of array of 8 MB or more...
they seem big array to me...

why not break that imagine in N parts as a math partition 
and allow N processor in rebuild redisign that imagine or pictures [i
don't know the right word] each that read write its own piece of sub
picture??

i think could be more fast
it would be enougth break the imagine in parts and assign each part to
the cpu...

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

#59467

On Thu, 02 Apr 2015 18:22:12 +0200, Rosario19  wrote:

>On Thu, 2 Apr 2015 09:06:24 -0700 (PDT), fir wrote:
>
>i seen you speak of array of 8 MB or more...
>they seem big array to me...
>
>why not break that imagine in N parts as a math partition 
>and allow N processor in rebuild redisign that imagine or pictures [i
>don't know the right word] each that read write its own piece of sub
>picture??
>
>i think could be more fast
>it would be enougth break the imagine in parts and assign each part to
>the cpu...
>

has someone one OS/cpu that allow assign some cpu to some thread?

i never have seen somthing like that...
i do not think here, this OS/cpu allow that;
pheraps it is better not to think to that

but in the near future [possible in the cellphone with 4 or 8 subcpu]
for me one can write something as that for see if it is good or not

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

#59500

On Thu, 02 Apr 2015 18:40:23 +0200, Rosario19 <Ros@invalid.invalid>
wrote:

>On Thu, 02 Apr 2015 18:22:12 +0200, Rosario19  wrote:
>
>>On Thu, 2 Apr 2015 09:06:24 -0700 (PDT), fir wrote:
>>
>>i seen you speak of array of 8 MB or more...
>>they seem big array to me...
>>
>>why not break that imagine in N parts as a math partition 
>>and allow N processor in rebuild redisign that imagine or pictures [i
>>don't know the right word] each that read write its own piece of sub
>>picture??
>>
>>i think could be more fast
>>it would be enougth break the imagine in parts and assign each part to
>>the cpu...
>>
>
>has someone one OS/cpu that allow assign some cpu to some thread?
>
>i never have seen somthing like that...
>i do not think here, this OS/cpu allow that;
>pheraps it is better not to think to that
>
>but in the near future [possible in the cellphone with 4 or 8 subcpu]
>for me one can write something as that for see if it is good or not


In Windows, for example, you can use SetThreadAffinityMask() to
(approximately) assign a thread to particular CPUs (cores).  In Linux
the equivalent is sched_setaffinity().

Many other OS's have similar functions, and both Windows and Linux
(and others) often have other ways to have a similar influence on the
scheduler.

Those don't prevent other work from running on the assigned processors
if it is of sufficient priority, and should a CPU become unavailable,
the OS will run the thread somewhere, based on other policy.

In general, there are only limited cases where playing with the
affinities is a good idea, OS's generally already try to minimize
thread migrations between CPUs, and, for NUMA-aware OS's, between
nodes.  Misusing that mechanism can easily become a pesimization if
the system architecture is not what you expected.

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

#59579

On Thu, 02 Apr 2015 18:22:12 +0200, Rosario19 <Ros@invalid.invalid>
wrote:

>On Thu, 2 Apr 2015 09:06:24 -0700 (PDT), fir wrote:
>
>>ps. as to executable this is pure winapi graphics app do not changes anything in system,
>>do not make any internet connection etc,
>>is not aany kind of malware
>>I am testing my system by antivir and do not detect i got any contagious virus here
>>(so as far as i can be sure 99.99% I think
>>it is not any kind of damege soft and can 
>>be just used)
>>
>>afaik shoul also work in linus through wine emulator, or maybe in wirtual machine or something
>
>i seen you speak of array of 8 MB or more...
>they seem big array to me...

yes what about

typedef struct foto 
{//  2D  or 3D foto
 unsigned   zmax;
 unsigned   ymax;
 unsigned   xmax;
 unsigned   *pixel;
 unsigned   *bpixel;
};

so one pixel would be one value 32 bits R G B  each 8 bit [0..255] +
one 8 bit used for other

bpixel would be the imagine where 1 pixel is 1 bit  ... one array of
bit where 0 means in (x,y,z) is void
          1 means in (x,y,z) there is one point 

>why not break that imagine in N parts as a math partition 
>and allow N processor in rebuild redisign that imagine or pictures [i
>don't know the right word] each that read write its own piece of sub
>picture??
>
>i think could be more fast
>it would be enougth break the imagine in parts and assign each part to
>the cpu...
>

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

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

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

csiph-web