%wp for %gr windows

Paul, would be nice to have a function which creates texture background in the %gr area same simple way as %wp doing that for the text window background. But besides this new CWP additional control there has to be also additional function to call the texture background each time before plotting different graph into the same %gr area. I think we discussed that before, so I am wondering was this already implemented or is it in the work or not yet planned.

Basically I do that by reading texture bmp files and then plotting them on %gr window with dimensions (ixGRsize, iyGRsize) while (ixBkgBMPsize, iyBkgBMPsize) are dimensions of texture bitmap this way

        do ivert =1, iyGrsize/iyBkgBMPsize(icurBkgDispl)+1
          do ihoriz=1, ixGrsize/ixBkgBMPsize(icurBkgDispl)+1
            i = dib_paint@((ihoriz-1)*ixBkgBMPsize(icurBkgDispl), 
     *                     (ivert-1) *iyBkgBMPsize(icurBkgDispl), 
     *      ihDibBkgFile(icurBkgDispl), 0, 0) 
	  enddo
	enddo

But the inconvenience is that I still need to read BMP files, separate names from directories, sort them, compare with the request and then plot like in the snippet above. But these texture files are already in my RESOURCES and are used for other text windows so would be great to reuse them for %gr. May be there exist workaround to do the same thing as I showed above with DIB_PAINT@ for %gr using bitmaps from RESOURCES ?

I will aim to take another look at this to see what happens when you put text on to a wallpaper background. It might be just a case of calling

int SetBkMode(HDC hdc, int iBkMode)

with the iBkMode set to TRANSPARENT

and hdc = clearwin_info@('GRAPHICS_HDC').

Dan

I did not read your post carefully enough and as a result I have fixed a different problem. When drawing plain text or %ws or %st on a %wp wallpaper, the text was not drawing transparently. I have fixed this and a beta salflibc.dll will shortly be available.

Regarding the actual issue that you raised, I have not thought about this before so if it had come up on the forum then I have missed it.

Presumably one can already paint an image into a %gr drawing surface and then draw over it (if this is not the case then please let me know).

What would you like ClearWin+ to do? Crop to the given size? Repeat the image to fill the area? Like many things, I guess ClearWin+ could do this if there were sufficient user interest.

That was great, I'm so glad that you misunderstood me and have fixed text transparency when the texts are printed on wallpaper textured surfaces, thank you very much, Paul. That was one of the major aesthetic negatives of CWP (only one-two others are left for CWP to be perfect out of the box, one is current alignment of controls on the top of the line instead of bottom and some on center, and another is the need for better fonts for formulas to look naturally).

As to wallpaper on %gr area, this is of course not urgent, since there exist a workaround by plotting texture bitmaps directly as tiles one by one as I showed above. Requesting it to implement I hope that optimized by the compiler developers this feature will be faster and in style with the other CWP controls. I did not mention also two minor problems with my method.

First, if I plot large (almost full screen) graphs with textured backgrounds very fast I see flickering on the graphics area despite I have latest and fastest PC and graphics (which is capable to deliver superdupersmoothest on earth and alien world 6000-9000 fps for my OpenGL graphics for example). I will prepare the demo when will have time. (Always thinking about double-buffering like in OpenGL but that would be an overkill)

And second, and I think I wrote here time ago, but did not see anyone confirmed that there is some problem causing my program to behave irrationally when I load too many background textures (like all 60 I have). They are memory hungry but may be there exist some memory leak or something. Was it possible or not to reproduce this on a small demo code I do not remember. May be someone experienced this too when they are using DIB_PAINT extensively? I also will try to find or write again the demo and try to reproduce the glitch.

I do not know how applying of wallpaper was implemented for just the regular text windows, but it seems it is done very well. If this could be done for the whole %GR area defined by its X,Y dimensions that would be probably fine. Or, ideally, applied just for arbitrary specified part of %GR area. The only potential difference with text window wallpaper is that the whole textured background (or only altered by user part of %GR area) must be rewritten again and again when you plot, say, another graphics. Things are that we often open one large window with graphics surface in it and reuse %gr for many graphs.

And I encourage all to use these WOW factor CWP features, the text and graphics abruptly get face lifting, a bit boring standard windows become appealing, your application you are opening every day for years completely changes its look and feel

I will add this to the wish list.

I am hopeful that I might have a solution to the control alignment problem but this is proving to be a major undertaking and it may be a wait before I report back.

Dan,

Can I suggest that after you have imported your bitmaps and placed them on the drawing surface, you save it. Then, if you have to redraw, you can just import that one image (and then draw on top of it). It may help with the flickering.

Eddie

Paul, The misalignment is more noticeable if you scale fonts to 0.9 or 0.8 of their default value. Exactly such kind of font sizes I find as a default in other GUI builders and they look more appealing and professional. And unfortunately exactly at these scalings CWP needs new tune up with the alignment on the bottom. I think with time the more people will come to CWP the larger will be demand for that. But also new alignment on the bottom though being more natural could still potentially break some older GUIs, so despite of lot of changes this potentially will need better to start moving there earlier ! I am not advocating for 0.8-0.9 decrease of default fonts, better for CWP to be able to scale naturally to any arbitrary font size

Eddie, Oh, thanks, that will definitely work /* I actually even did that many years ago when computers were too weak and flicker was too annoying but did not use this part of the application since then and as a result completely forgot about this trick... Trying to find it..Damn Alzheimer ... The code became so large that some things do not cross the view for decades. And sometimes due to that things become even worse, since I do not document anything but instead use long self-documenting variables, yesterday I was trying to find LU-factorization subroutine and failed. 'LU' is too short to get through tons of false positives editor's search finds 😦

On another note, I've read in this group that someone somehow did kind of double buffering with usual FTN95 graphics plotting everything first on virtual screen and then displaying the content when it is done. How in short this could be done?

/* On the note 2, all that flicker I see is kind of surprising. The DIB_PAINT@ was doing good fast job lately and I did not notice any flicker on other animations....may be I have some bug in my code and something is plotted two or more times. Curious if anybody here doing any animations and see the flicker?

Dan,

Me again. Yes, scaling the default font is often not very good. Remember it scales to no better than 1 pixel, probably worse, because the default font has a fixed range of sizes. Better to select a font like Trebuchet (Vista) or Segoe UI and scale that. Whatever you use may change if the user's default setting is 'large fonts'. These issues also resound through the positioning commands.

Also, you may need to use different font scaling for a hi resolution but physically small screen.

Eddie