🚀 go-pugleaf

http://www.progdigy.com/?page_id=7

Thanks John. But what I mean is some higher level, advanced  set of 
functions/classes based on this wrapper :-)

"John" <NoSpam@NoSpam.com> wrote in message 
news:48901a6f$1@newsgroups.borland.com...
> http://www.progdigy.com/?page_id=7 

> Thanks John. But what I mean is some higher level, advanced  set of 
> functions/classes based on this wrapper :-)

I've recently written a new (as yet unpublished) set of components very like my 
Drawing Objects components (http://angusj.com/delphi/) that uses GDI+. HOWEVER, 
They remain unpublished because, when combined in large numbers, their drawing 
is too slow for real world use. Since they're descendants of TGraphicControl, 
each one get redrawn whenever any part of the form needs repainting, so moving 
and adjusting these objects dynamically when there's more than a dozen or so 
objects on the form is too slow for practical use. Nevertheless, if you're needs 
are for static objects (ie not to be dynamically redesigned by the end user), or 
for only small numbers of objects and you think they might still be useful, I'd 
be happy to upload them to attachments if you want to try them out. These 
Drawing Objects are easy to use with PenEx and BrushEx wrapper classes which 
encapsulate the TGPPen and TGPBrush classes, exposing the usual TPen and TBrush 
properties while including an Opacity property. (There are also PenEx.GPPen and 
BrushEx.GPBrush properties if you need direct access to the GDI+ objects 
directly for more complex GDI+ features such as gradient brushes etc.) They're 
also freeware if that helps :).

In the meantime, I'm considering rewriting them again to be used in Graphics32 
where these speed issues can be overcome. 

Hi Angus,

> In the meantime, I'm considering rewriting them again to be used in 
> Graphics32 where these speed issues can be overcome.

You should take a look at AggPas at:

http://aggpas.org/

It is really good and easy to use. I for sure find it a lot easier to use 
than graphics32.


Kind Regards
Roy Magne Klever

"Roy Magne Klever" <a@b.c> wrote in message 
news:489101a4$1@newsgroups.borland.com...
> Hi Angus,
>
>> In the meantime, I'm considering rewriting them again to be used in 
>> Graphics32 where these speed issues can be overcome.
>
> You should take a look at AggPas at:

Yes, I've been looking at AggPas too and it too seems an impressive package.

However, the problem is that where objects are defined with vectors, they 
eventually have to be rasterised to be displayed. What I'm still contemplating 
is the best way to store a rasterised image of each object (and TBitmap32 looks 
attractive) so they can be quickly blended onto the 'display' (eg another 
bitmap, a form or a printer canvas). The way I understand things is that both 
GDI+ and AggPas are good at rendering vector objects into raster images, but 
since this is relatively slow (too slow), I think I'll also have to store a 
rasterised representation of the image in the object, so they can be quickly 
blended onto the display canvas. At the moment my objects don't store any 
rasterised information but simply render the vector defined objects directly 
onto required canvas, and this is generally too slow if there are many objects. 
Anyhow, my understanding is that AggPas could be a very good alternative to GDI+ 
but it won't help me with storing rasterised images in memory.

I've ever compared the speed of drawing primitive shapes with gdi+ and 
TAggPas2d, both are drawn on Graphics32's TPaintBox32, GDI+ is way faster 
than AggPas...

"Angus Johnson" <angus@undisclosed.loc> wrote in message 
news:48911cd1$1@newsgroups.borland.com...
>
> "Roy Magne Klever" <a@b.c> wrote in message 
> news:489101a4$1@newsgroups.borland.com...
>> Hi Angus,
>>
>>> In the meantime, I'm considering rewriting them again to be used in 
>>> Graphics32 where these speed issues can be overcome.
>>
>> You should take a look at AggPas at:
>
> Yes, I've been looking at AggPas too and it too seems an impressive 
> package.
>
> However, the problem is that where objects are defined with vectors, they 
> eventually have to be rasterised to be displayed. What I'm still 
> contemplating is the best way to store a rasterised image of each object 
> (and TBitmap32 looks attractive) so they can be quickly blended onto the 
> 'display' (eg another bitmap, a form or a printer canvas). The way I 
> understand things is that both GDI+ and AggPas are good at rendering 
> vector objects into raster images, but since this is relatively slow (too 
> slow), I think I'll also have to store a rasterised representation of the 
> image in the object, so they can be quickly blended onto the display 
> canvas. At the moment my objects don't store any rasterised information 
> but simply render the vector defined objects directly onto required 
> canvas, and this is generally too slow if there are many objects. Anyhow, 
> my understanding is that AggPas could be a very good alternative to GDI+ 
> but it won't help me with storing rasterised images in memory.
>
> 

Thanks Angus, although speed is very concerned, I'd like to have a look on 
these classes :)


"Angus Johnson" <angus@undisclosed.loc> wrote in message 
news:4890f248$1@newsgroups.borland.com...
>> Thanks John. But what I mean is some higher level, advanced  set of 
>> functions/classes based on this wrapper :-)
>
> I've recently written a new (as yet unpublished) set of components very 
> like my Drawing Objects components (http://angusj.com/delphi/) that uses 
> GDI+. HOWEVER, They remain unpublished because, when combined in large 
> numbers, their drawing is too slow for real world use. Since they're 
> descendants of TGraphicControl, each one get redrawn whenever any part of 
> the form needs repainting, so moving and adjusting these objects 
> dynamically when there's more than a dozen or so objects on the form is 
> too slow for practical use. Nevertheless, if you're needs are for static 
> objects (ie not to be dynamically redesigned by the end user), or for only 
> small numbers of objects and you think they might still be useful, I'd be 
> happy to upload them to attachments if you want to try them out. These 
> Drawing Objects are easy to use with PenEx and BrushEx wrapper classes 
> which encapsulate the TGPPen and TGPBrush classes, exposing the usual TPen 
> and TBrush properties while including an Opacity property. (There are also 
> PenEx.GPPen and BrushEx.GPBrush properties if you need direct access to 
> the GDI+ objects directly for more complex GDI+ features such as gradient 
> brushes etc.) They're also freeware if that helps :).
>
> In the meantime, I'm considering rewriting them again to be used in 
> Graphics32 where these speed issues can be overcome. 

"Edwin" <edwin@domain.com> wrote in message 
news:48912563@newsgroups.borland.com...
> Thanks Angus, although speed is very concerned, I'd like to have a look on 
> these classes :)

OK, I'll upload them to the attachments newsgroup shortly. 

Hi Angus,

> However, the problem is that where objects are defined with vectors, they 
> eventually have to be rasterised to be displayed. What I'm still 
> contemplating is the best way to store a rasterised image of each object 
> (and TBitmap32 looks attractive) so they can be quickly blended onto the 
> 'display' (eg another bitmap, a form or a printer canvas).

Ah, i see your point here :) and agree with you.


Kind Regards
Roy Magne Klever 

Hi Edwin,

> I've ever compared the speed of drawing primitive shapes with gdi+ and 
> TAggPas2d, both are drawn on Graphics32's TPaintBox32, GDI+ is way faster 
> than AggPas...

Ah, i did not know this.

Kind Regards
Roy M Klever 

Thanks Angus, I had a look at - the first question I come up with is that 
the class should not be derived from TGraphicControl, whereas it should be 
independent from the TControl hierarchy and allow the client to assign an 
HDC to draw on...

"Angus Johnson" <angus@undisclosed.loc> wrote in message 
news:48912d0f$1@newsgroups.borland.com...
>
> "Edwin" <edwin@domain.com> wrote in message 
> news:48912563@newsgroups.borland.com...
>> Thanks Angus, although speed is very concerned, I'd like to have a look 
>> on these classes :)
>
> OK, I'll upload them to the attachments newsgroup shortly. 

Sorry, I forgot to say that the PNG is very nice ;-)

"Angus Johnson" <angus@undisclosed.loc> wrote in message 
news:48912d0f$1@newsgroups.borland.com...
>
> "Edwin" <edwin@domain.com> wrote in message 
> news:48912563@newsgroups.borland.com...
>> Thanks Angus, although speed is very concerned, I'd like to have a look 
>> on these classes :)
>
> OK, I'll upload them to the attachments newsgroup shortly. 

> Thanks Angus, I had a look at - the first question I come up with is that
> the class should not be derived from TGraphicControl, whereas it should be 
> independent from the TControl hierarchy and allow the client to assign an HDC 
> to draw on...

It is derived from TGraphicControl because it's a basic visual component with a 
canvas property.
Anyhow, there's a PaintToCanvas(canvas: TCanvas; Offset: TPoint) method so the 
object can be painted to any canvas, not just the control's canvas.
So you can do something like ...

var
  i: integer;
begin
  for i := 0 to form.componentcount -1 do
    if form.components[i] is TDrawBase then
      with TDrawBase(form.components[i]) do
        PaintToCanvas(printer.canvas, Point(left,top));
end;