angusj

@Rollo62 Thank you for the encouraging feedback. I'm glad Image32 is behaving as advertised 😁. I'm afraid Image32's SVG support is pretty much read-only. There is an extremely basic SVG writer, that's separate from the reader, and really just proof of concept. The reader was designed for speed, not for editing as you've discovered. Regarding hashing: I'm assuming it's faster than string comparing, which there are many, but honestly I haven't tested if it makes a difference and how much (and yes it does complicate the code). Regarding UTF8String: Just about every SVG is written in UTF-8 which given it was initially created for web graphics makes sense. So again for performance the file isn't converted to Unicode, and the XML parser just creates pointers into the UTF-8 stream. No, not at the moment. I do intend to convert the reader to read-write at some stage. However I'm not sure when that will happen as I'm taking a much needed breather after spending a lot of time on this. I also have another project (my Clipper library) that's been stuck in a partial update for several years that's probably my next priority. If there was huge demand for read-write SVGs I might make that the higher priority but my perception is that reading SVGs is/was by far the bigger need. Cheers.

Image32 will happily convert SVG to PNG/BMP/JPEG. http://www.angusj.com/delphi/image32/Docs/Overview.htm http://www.angusj.com/delphi/image32/Docs/Units/Img32.Fmt.SVG/_Body.htm

I started with open source back on Compuserve, before the Internet existed. My first PC had Z80A CPU, CP/M OS plus dual 5.25" floppies.

No worries Rob. Judging by the number of 'likes' etc I'm getting I suspect a few others have made the same mistake. Keep it up! 😜

😁

Hi Tim. Yeah, writing to SVG is currently barely functional (unlike reading them). Also, you can't do it the way you write/save images of other formats. There is an SVG writing demo, but it's very primative. I think for the foreseeable future is best to consider SVG as read only.

Hi Rob. I suspect you're mixing up Image32 with Graphics32. 😜.

Resource Hacker A resource editor for 32bit and 64bit Windows applications. It's both a resource compiler and a decompiler - enabling viewing and editing of resources in executables (*.exe; *.dll; *.scr; etc) and compiled resource libraries (*.res, *.mui). Resource Hacker also provides many options for compiling and decompiling resources from the command-line. http://www.angusj.com/resourcehacker/ Download: http://www.angusj.com/resourcehacker/reshacker_setup.exe

Noted. Cheers, and thanks again.

Hi. I've downloaded and looked at your NameMapUnit unit and have the following comments: 1. Firstly, great speed, so thanks and well done. 2. I suggest adding an "InitialCapacity" parameter to your TMapBase.constructor 3. It seems to me that your TMapBase.Rehash method, which concurrently removes and reinserts items into FItems, risks some duplication. (OK, on further testing this doesn't seem to be a problem.) Anyhow, there may be a marginal improvement by reinserting TMapItem items instead of recreating them. Cheers.

Thanks KodeZwerg. 😁

Anders, I strongly disagree with your cowboys comment. There were and are only a very few Graphics32 contributors with write permissions to the library. And all of those contributors made significant contributions. None fit your profile of "Rides into town, shooting right and left and then rides out of town leading a mess behind". Yes, most of us have left, presumably for different reasons. As I've stated elsewhere, I finally left Graphics32 when I realised that it had reached the point that it needed to be completely rewritten, and even just trying to fix things (eg writing extensive documentation) was a waste of time.

And adding to that confusion is TDrawMode and TCombineMode.

Anders, I didn't claim that the Image32 projective transform algorithm was faster, but that it was more flexible. Projective transform require a set of 4 source coordinates and a set of 4 destination coordinates indicating source and destination quadrilaterals. While both algorithms obviously require the user to specify the destination quadrilateral, the Graphics32 algorithm simply uses the source image bounds as the source quadrilateral, whereas the Image32 algorithm allows the user to define a source quadrilateral too (which can be very useful). Both libraries support 64bit compiling. However, if you're referring to 64bpp (bits per pixel) images then neither library support this. Both libraries load and manipulate images using 32 bpp (hence the 32 in their names 😁), though images can still be saved to file using lower color resolutions. But too many options just makes a library unhelpfully complicated for the average user.

That was indeed my initial intention. However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR). I'd disagree with Anders on that, though of course I could still greatly improve Image32's design. It's fair to say the TImage32 class that's at the core of my Image32 library does have a large number of methods related to loading and saving images, as well as a number of image manipulation methods (including hue adjustment and basic afine transformations - scale, rotate etc). But most of these methods (or similar) also appear in Graphic32's TBitmap32 class. IMHO Graphic32's TBitmap32 is much more monolithic, as it containing a whole host of line rendering methods (as mentioned above) and text (polygon) rendering methods too. These really shouldn't be there, as these operations are much better served by the functions found in Graphic32's Gr32_VPR unit. Further, TBitmap32's line rendering methods will only draw 1 pixel wide lines which is extremely limiting. So I would argue that my TImage32 class is much less monolithic than the TBitmap32 class. Almost none of my Image32 libray uses code from Graphics32. The excepion to that is a small amount of code in my Image32_Draw unit where the polygon renderer uses a memory allocation technique I copied from Mattias Andersson's Gr32_VPR unit. (When comparing Image32 rendering performance with Graphics32, I couldn't figure out how Mattias' rendering was so efficient.) Nevertheless my polygon renderer is based on https://nothings.org/gamedev/rasterize , though it still isn't quite as fast as Mattias' renderer. I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution). With regard to which library is better, I suggest if you're familiar with Graphics32, or if polygon rendering performance is critical, then use Graphics32. However, Image32 does offer several benefits over Graphics32. It's a much simpler library to learn and use IMHO and it contains better cross-platform support with both Lazarus and FMX options.