forums.silverfrost.com

[JohnCampbell]

This post has highlighted to me that DIB is another option for updating the active graphics window.
I have developed my own hidden line shading, based on the pixel depth. To update the active window, in the past, I have:
1) Started with Draw_point@ to update the pixel colour and get_RGB_Value@ to get the pixel colour of the active window.
2) I moved from draw_point@ to draw_line_between@ to improve the update rates.
3) Recently I have started to introduced user_surface into “winio@ ('%`^gr grey, user_resize, rgb_colours, full_mouse_input, user_surface]&'” to allow direct addressing of the graphics surface. I have not fully tested this option.
4) DIB offers a way of retrieving or setting the RGB colours for the active screen, using a single call, presumably much quicker than draw_point@ but possibly slower than direct addressing. It clearly can access any virtual graphics surface. Any size can be managed when character*1 PARRAY(3,mx,my) is declared allocatable.
User_surface has the advantage of direct addressing of the graphics information. The pointer changes value with a window resize and (I hope) with calls to select_graphics_object@ (is this the case ?). It has the disadvantage of a more complex addressing method, as in:

[silicondale]

Excellent thought, John - as long as you bear in mind the x-direction 2048 pixels limitation. If there's a way to get around that, it would be superb!

Meanwhile, I'm now working along the SVG route. Being vector-oriented rather than pixels, and also providing the scaleability, it has some distinbct advantages for mapping - I am working on geological and mine design applications. SVG does also offer a number of area-fill options, so usable for shaded maps too, not just line drawings. Small disadvantage for web appliocations is that it doesn't have the same web browser support as JPEG and GIF - it can be displayed in web pages, but through <object> rather than <img>.

I've also found that generating SVG is much faster than JPG or GIF, at least for the trivial test examples I've been running. File sizes tend to be quite small as well. Although the XML format is verbose, there's no need to store anything for blank areas, so for relatvely sparse graphics it's ideal.
_________________
(Steve Henley)

[JohnCampbell]

Paul or Eddie,

Further to my previous post, could I ask:
1) Does the '%gr[user_surface]' allow the direct addressing pointer to change when select_graphics_object@ selects a virtual window ?
2) Would you expect that a DIB interface (with the selected graphics object) could perform at a similar speed to direct addressing, especially in comparison to the draw_point@ and Draw_Line_Between@ update approach.

It appears that there is a 2048 X limit with the DIB interface. Are you able to identify any possible limit in this area.

If user_surface does not support addressing the virtual screen, DIB may be a more flexible alternative. And, if DIB is significantly slower, I may need to use both.

I would appreciate any advice you may be able to provide.

John

[PaulLaidler]

I have managed to find a 2048 limit (in two places) and the limit proves to be avoidable. So this problem has now been fixed for the next release of salflibc.dll.

Regarding John's questions 1 and 2, currently user_surface has its own unique direct addressing pointer which cannot be changed (the whole thing is rather complex so I cannot be 100% sure that I am providing the correct answer to the question that you ask).

draw_point@ and draw_line_between@ provide interfaces into the API SetPixel and MoveTo and LineTo but I don't know how these functions perform in comparison with direct addressing.

[JohnCampbell]

Paul,

Thank you very much for identifying this limit. It will make DIB more flexible.

I have recently been reviewing the way I manage my graphics information using Clearwin+ and am finding I don’t fully understand what the limitations are for some methods.
Some functionality I am mixing includes:
• I have my own hidden line painting window (X,Y,Z,C), which I “dump” to the selected graphics window. This has to be managed when including text.
• I have introduced screen window resizing, which I understand requires new memory allocation for the resized window.
• I use both the screen window and other virtual windows via create_graphics_region@ and select_graphics_object@ .
• I am now scanning the selected window to check the colour tablet being used for .gif dumps.

My %gr call has expanded to:
i = winio@ ('%`^gr[grey, user_resize, rgb_colours, full_mouse_input, user_surface]&', &
1024, 768, & ! screen dimension when not maximised
ptr_RGB_Address, & ! screen address for rgb surface ( not sure of the order ? )
w_handle, & ! supplied window handle defined in crtstart
mouse_back_func) ! ^ call back function for mouse and resize

It appears to me that “user_surface” points to a bgr storage format, while DIB points to a rgb_format. For user_surface, each row is stored in an integer*4 vector in blue green red order, while DIB uses a simpler integer*1 (3,h,v) format in rgb order. Have I got this right? If I have, what storage format do create_graphics_regions use?

Some things I do not understand, related to this are:
As there are a lot of legacy colour formats, is the screen window always stored in memory, or does this require rgb_colours or user_surface ?
Does “ptr_RGB_Address”, which is a memory byte address, point to the screen information or the select_graphics_object ?
Do legacy colour formats influence answers to these questions, making the memory management more complex?

Would it be possible to have a routine like:
get_select_graphics_object_address@ (Byte_Address, WIDTH, HEIGHT, NBBP, ERCODE )
where “NBBP” (the number of bits per pixel) could be expanded to indicate the memory storage format, if required.
Depending on the answers to questions above, this may be a useful addition.
It may create a faster alternative to RECOVER_DIB_BLOCK@, allowing direct addressing of the selected graphics object.

The help file on “Direct manipulation of the graphics surface” also refers to use of window_update@ and GdiFlush(). Would the use of these calls be necessary in a Windows XP or 7 environment? My suggested routine may conflict with these calls.

I would appreciate what advice you are able to provide.

John

[PaulLaidler]

Having already spent a great deal of time fixing the problem of the limit and given the complexity of the library and of your questions, I find it very difficult to provide any insight for you.

I am aware of changes in the rgb and grb order depending on the context. The only comment I can add at the moment is to note that I did find it helpful to look at the PARRAY by viewing the memory with SDBG.

I hope that you will understand that there is always one more question after the last and there are many demands upon my time.

[silicondale]

Thanks to Paul for identifying the reported problem - and huge thanks also to John for the detailed investigation! I think I now have a couple of workable solutions for the immediate future - indeed three workable solutions if the new salflibc.dll will remove the 2048 X limitation.

In summary -
* I can generate SVG which operates entirely independently of the Clearwin+ graphics and generates externally viewable graphics files - but not as standard images like jpeg or gif. Based on coding in the public domain I am now building my own simple SVG library which ultimately may be useful to make generally available, as it seems there isn't one already (well there is a Fortran SVG library from FENIA but at first glance this one seems unnecessarily complex).

* Using the Clearwin+ graphics enbvironment I can directly export GIF files without the 2048 x-pixels limit, using the current salflibc.dll

* If the the next salflibc.dll removes the limit, then I can use this to generate jpg files too.

I understand John's further questions and agree that it would be good to know in more detail just how the Clearwin+ graphics works, but I think that is the subject for another discussion thread!
_________________
(Steve Henley)

[DanRRight]

I do not like the mess around GIFs patented functionality but it is still good to create animations from numerical simulations for Powerpoint presentations.

Question to Paul:
Clearwin+ can now take GIF files as a resource. Any chance we will get put_dib_block@ to save in GIF format?

Question to ALL:
-Do you know library which we can call from Fortran to automate creation of living GIFs ?
-and Fortran callable library which transforms pcx (or BMP which are lossless format in Clearwin suitable for animation purposes) into gif? (i have used one 20 years ago with DOS and Salford FTN77 call to DOS prompt)

Question to OP:
Can SVG do the functionality of living gifs?

[silicondale]

Hello, Dan - I'm not an expert on graphics formats, but when researching it, I'm sure I saw some animated SVG images. The real beauty of SVG, though, is that it's an open XML format that requires no special coding to export - you just use ordinary Fortran sequential writes. I've put together a small subroutine library that does what I need, and happy to send you a copy, or there are a couple of published fortran SVG libraries (source available free on the web) though these are both much more complex (and comprehensive) than I needed.
-Steve
... ps - just googled and got this -
http://en.wikipedia.org/wiki/SVG_animation
which answers your question, I think!
_________________
(Steve Henley)

[PaulLaidler]

Dan

There is an undocumented routine EXPORT_GIF@ which has the same arguments as EXPORT_BMP@. The interface is

[JohnCampbell]

Dan,

I do not know what "living GIFs" are, but I do create single .gif images using the following code.

[DanRRight]

Great that gif export is there.

I had in my code outputs in BMP & PCX already programmed in and adding GIF option was just 1 min work. I also added c_external declaration but by some reason the output creates the file of zero size...BMP and PCX work fine. What the heck this could be? An older Salflibc ?

"Living gif" i've heard people call GIF89a (or something like that) standard for animated gif files . Living GIF is still used because uses 8bits per color instead of 24 which is useful to reduce size when compressed. Here is an example

[PaulLaidler]

All of the gif stuff has been in salflibc.dll for a long time but not exposed because of earlier copyright limitations.

[Wilfried Linder]

A very simple way to export to GIF is the (also undocumented?) function EXPORT_IMAGE@(file_name). The output format is given by the extension of the file name (BMP, PCX, JPG or GIF).

[DanRRight]

Your way of GIF creation works, Wilfried. I do not know what's wrong with the other way...may be something is corrupt in my code. Thanks to all anyway, will find the bug eventually.

John, How specifically do you think palettes have to be implemented with only 256 colors so that it wil be simple to use them? 6R * 6G * 6B + 40?

Also, do anyone know the utilities which already implemented different palettes for 24bit RGB so that you change value from 0 to 1 and the color goes from darker end of palette to bright one? I have done several my own like those ones but will be happy to get something new too. here red palette is very simple, but rainbow already need some programming. Or may be somebody realized something like "Universal Clearwin Palette Builder" when you can make arbitrary ones with just few mouse clicks?