Single-images arrays have always been a very last resort for me, as they are so inefficient. The advanmtage of a separate image for each cell is that just 28 distinct images can be used to illustrate any possible FIDE game from end to end. A stored single image of the same resolution requires the equivalent of more than twice that for just the array position, The Cyclohex array image takes up 104 kilobytes, far larger than the text of any variant, and I would hate to illustrate a whole game of that. Another problem with single-image array files is that the mechanism for loading them does not always work. It did not, for example, when I tried to post such a file for VeCoTha in place of tabulated multiple images, and instead I had to resort to an emergency Ascii Art diagram. In case anyone asks, there is never any error warning, it just shows as an invalid image on-screen after I edit the page to incorporate the image.
Of course doing multi-image diagrams raw has its costs as well, which is why I emphasise stored. That is where ffen diagrams come in, as regards traditional computing. As far as the HTML document is concerned it is a calculated image, taking up not much more space in the text of the page than a single image but without an image file's use of memory outside the text of the page either. As far as a large enough screen is concerned they also behave like a single image, at least if nothing else is on the same line, and desktop monitors have been getting bigger all century. The problem is how they behave on the mobile devices to which this thread's title refers - and I am guessing that Ascii Art is not very mobile-friendly either.
Now there are various facilities for playing many of the variants on these pages, and I would be surprised (and indeed disappointed at the capabilities of programming) if they generated an image file for every position that ever came up. In terms of more typical programming, It would be the equivalent of every control on a Visual Studio form replicating the entire definition of tha control. What I do not know is how the playing facilities stand up to use on a tiny screen. If they can be made to behave as single images even on-screen, surely something can be done somewhere along the line that can be done to make ffen diagrams do so as well. It would be a shame to lose such a useful shorthand for want of it functioning on mobile devices.
Of course doing multi-image diagrams raw has its costs as well, which is why I emphasise stored. That is where ffen diagrams come in, as regards traditional computing. As far as the HTML document is concerned it is a calculated image, taking up not much more space in the text of the page than a single image but without an image file's use of memory outside the text of the page either. As far as a large enough screen is concerned they also behave like a single image, at least if nothing else is on the same line, and desktop monitors have been getting bigger all century. The problem is how they behave on the mobile devices to which this thread's title refers - and I am guessing that Ascii Art is not very mobile-friendly either.
Now there are various facilities for playing many of the variants on these pages, and I would be surprised (and indeed disappointed at the capabilities of programming) if they generated an image file for every position that ever came up. In terms of more typical programming, It would be the equivalent of every control on a Visual Studio form replicating the entire definition of tha control. What I do not know is how the playing facilities stand up to use on a tiny screen. If they can be made to behave as single images even on-screen, surely something can be done somewhere along the line that can be done to make ffen diagrams do so as well. It would be a shame to lose such a useful shorthand for want of it functioning on mobile devices.