#65 Smart image handling in FMSLogo - responsive design.

[Manfred Zindel]

When we developed some new Project with FMSLogo, we experienced something astonishing. We asked FMSLogo to give us a graphics area of 10000 x 10000 und our viewport was below 1280 x 1080 - because a display resolution of Full HD 1920 x 1080 and a display resolution of 1.5 just left us a vieport of a little less than 1280 x 720. But the image we wanted to load was 2300 x 1078. So we loaded the image and saw, that it would have to be scrolled to see all of it. So we tried a ZOOM of 0.5 and this nearly shrinked the image into the viewport.

Our big surprise came when we changed the call by doing zoom before (!) the loading. And the image was at once loaded as if it had the smaller size from the beginning.

Well, if we have the user's data from MACHINE we can do some responsive design this way!

My questions: Is the loaded image nevertheless available in full resolution, so that it's enlargement by a subsequent ZOOM 1 would show the full resolution (partly behind the scene)? And is the observation correct that the pre-ZOOM cares for faster loading?

[David Costanzo]

I'm not sure what you're asking, but swapping the order of running BITLOAD and ZOOM shouldn't change the outcome. BITLOAD copies the image to the drawing surface at the exact size of the image. ZOOM changes how much of the drawing surface you see, but it doesn't change what's on the drawing surface. If you BITLOAD while zoomed out or zoomed in and then you run "ZOOM 1" to get back to the 1:1 size, it'll be as if you never had zoomed. You'll see this behavior for all drawing commands, not just BITLOAD.

There are too many factors that can influence performance for me to speculate if BITLOAD while zoomed out is faster than BITLOAD while at "ZOOM 1". You're better off measuring the timing yourself and then trusting the empirical evidence for your specific setup. Be aware that you might also be observing the effect of the operating system caching the file when it was first loaded, so that all subsequent loads are faster.

[Manfred Zindel]

I see. I've got still another question concerning ZOOM. As ZOOM can be used both, interactively and programmatically, the program cannot know whether during the run an interactive ZOOM has been performed. So it would be better, if the program could ask internally for the current size of ZOOM. When items 16 and 17 were added to MACHINE, it allowed us to see from our procedure where the scroll position has gone, and we used this often since then. So I ask, whether there is a possibility to find out the current ZOOM factor in a program.

[Manfred Zindel]

Regretably there are more problems when using ZOOM. We created a BUTTON with the FMSLogo screen as parent. And it worked womderful when ZOOM was 1. But as soon as ZOOM got another value, say 2 or 0.5, the BUTTON went crazy. First I thought, that it was gone, but it only jumped away in an unpredictable way. It did not simply scale like the ZOOM nor did oit keep its original size. Well, so I thought, it would be bettwer to create an own window for this button. This is not really smart, and it has another problem to ask the users to learn all about dialog units. There is still the workaround to use BITFIT instead of ZOOM when scaling images. But this is still less smart, becouse you first have to show the wrong size and BITCOPY or BITCUT it and then get it to the desired size using BITFIT. All this is not amusing for beginners. So some of them expect the real thing when they use AI. AI will be funny, fast and perfect - so why bother about learning t program, if we have AI - let's do vibe coding and all problems are gone.

[David Costanzo]

It's true that the dialog widgets that are placed on the drawing surface are incompatible with ZOOM.

The feature request you made, to have the current ZOOM level be available by MACHINE makes sense to me. If ZOOM had followed Logo conventions, it would have been named SETZOOM with ZOOM outputting the current zoom level. It's too late to correct that now. Your idea of adding it to what MACHINE outputs has minimal risk to breaking backward compatibility, so it's something I'd be willing to implement.

That said, there's still a cost to pay to implement, document, test, and maintain the feature. Given that no one else has ever asked for a way to get the ZOOM level, I expect that you would be the only one to ever use it. After your last post, it sounds like even you wouldn't be able to use it because of the widgets problem.

So do you still need it to solve whatever problem you're trying to solve? Or even with an extended MACHINE, would you still be unable to use ZOOM?

[Manfred Zindel]

Thank you, David, for your answer. You made it clear that widgets on the graphcs screen are not compatible with ZOOM. This is regretable, but no disaster. I can still use a window as parent of the widgets, even if that is not so smart and comfortable as using them directly on the graphics screen. But it's good enough. When using a window, I'll have to rely on dialog units, but you already gave us a procedure to handle them, which worked perfectly already over years.

Concerning the possibility to extend MACHINE, I have to say, that it's not only for me, but for as many students aged 13 years or more as possible.

I can't tell the whole story, but just the essentials:

I'm the owner of pbreport, founded in 2001, a small company assisting schools and other educational efforts.. We were successful in competence analysis and coaching for 16 years until 2023, and all the "intelligent", precisely printed documents we used for over 1500 young people were made with FMSLogo. All the psychological tests were mathematically evaluated and prepared for print using FMSLogo - while our concept was constantly evolving and well-known.

As we had the experience that we could rely on FMSLogo, we decided in 2020 to begin a project called KISS.lgo to extend the language by what we now call a framework with the same name. The first thing we tried was "Little Helper", supported by David.

Most of this development we could do in FMSLogo itself. We improved "Commander's Little Helper" (as we call it now). and developed a constantly increasing set of small libraries - made for polygons, color management, text and font management, three kinds of bezier curves able to transform plolygons. and probability and statistics.

All this we tested in two schools (one for ambitious students, one for immigrants) in Paderborn. This resulted in a lot of changes and new ideas. This lasted during the last two school-years.

Now we plan to use all the contents in a series of coursebooks, and the first, introductory one will be available in German in November, in English, Spanish and Chinese in Spring 2026. The new software of course will be free and backward compatible with FMSLogo. Even the EDALL button remains unchanged again. The coursebooks cannot be free, but will be as cheap as possible.

pbreport invested a lot in it, but we were supported by ZIP (Zukunft durch Innovation), a governmental project over many years and by the Foundation "Osthushenrich-Stiftung" - they supported us for half a year.

Now we face a deadline of the end of October to publish the introductory coursebook in German.

So we are sure that all we do is for a lot of young people or even adults.

Back to your question, if we really need ZOOM in MACHINE. Yes we do, and it would be part of the contents of the introductory coursebook. You, David, built also the SCROLL information into MACHINE, and we used this to develop a small library for navigating through the whole visible and invisible graphics screen. It has been very successful since it was implemented.

[David Costanzo]

I opened Feature Request #143 to track the addition of the screen's scale to MACHINE's output list. It will be included in FMSLogo 8.5.0.