Support for high DPI and multiple monitors

[skiwi]

Sparx EA is an application that is most usable using multiple monitors IMHO.


I have submitted a feature request  for Sparx EA to become Per-monitor DPI aware, and to have UI elements updated to work with high-DPI monitors, to automatyically have fully and partially (where the title bard and menu is off screen) off monitor windows and dialogues to automatically snap back to on monitor.


See for example High DPI Desktop Application Development on Windows


tia


Simon

[Paolo F Cantoni]

Sparx EA is an application that is most usable using multiple monitors IMHO.


I have submitted a feature request  for Sparx EA to become Per-monitor DPI aware, and to have UI elements updated to work with high-DPI monitors, to automatically have fully and partially (where the title bar and menu is off-screen) off monitor windows and dialogues to automatically snap back to on monitor.


See for example High DPI Desktop Application Development on Windows


tia


Simon

+10

On my Surface Book 2, it goes Ga-ga very often (if I have the wrong Workspace enabled).  Although the problem is partly Microsoft (hardware) caused.

Paolo

[Richard Freggi]

Seconded and thirded.  I often run real-time stakeholder workshops on lo-res projectors and on Skype/Zoom and I get errors and wrong mouse positions all the times.  In previous post I think SParx's Simon mentioned it's a Microsoft Win 10 problem and not much Sparx can do about it.  If only my company let us use Linux OS....

[qwerty]

If only my company let us use Linux OS....

I doubt it would help since you need Windoze in a box anyway. However, my Mac handles screen changes well even for the Windoze box. IIRC XP was not that forgiving as 7 is now. Maybe 10 got worse in that respect?

q.

[Eve]

In previous post I think SParx's Simon mentioned it's a Microsoft Win 10 problem and not much Sparx can do about it.

Those issues are for the System DPI awareness mode. In that mode, an application is expected to handle any single DPI setting at load. Microsoft APIs then automatically scale all drawing and coordinates when a different DPI is used (because of a different monitor or settings change.) My memory tells me that sometimes those translations fail, such as when moving a window between a monitor it feels like the scaling is applied to the whole workspace instead of just one screen, and the non-client (eg shadows) draw at the wrong size.

Because all the APIs are return scaled values when this is happening, we can't even detect it. Well, we could if we created another application that is per monitor aware and sent the data back to EA. Then we could theoretically reverse engineer whatever the bugs in Windows are and attempt to compensate.

As for Per Monitor DPI awareness, at the moment it's an all or nothing upgrade. It's a mammoth undertaking, although one that does need to be done at some point. Currently it's not supported by our GUI library, which means there's little we can do.

[skiwi]

My response from support, and I quote

Version 15 is introducing new icons/images based on vectors rather than bitmap system for the high DPI monitors.
 EA currently supports multiple monitors with different resolutions - this is a Windows feature not an EA one.
 So hopefully the change in the imaging will19031663 cover both points,

[Eve]

Unfortunately, what support is describing would only help if you were reporting the icons getting blurry at high dpi. Even then only for a single DPI setup.

[timoc]

My response from support, and I quote

Version 15 is introducing new icons/images based on vectors rather than bitmap system for the high DPI monitors.
 EA currently supports multiple monitors with different resolutions - this is a Windows feature not an EA one.
 So hopefully the change in the imaging will19031663 cover both points,

SVG would seem to be the logical choice for a scalable vector graphical icon set. It was invented for that purpose.
Being able to SVGs, and even better, SVG templates for elements, icons, and embedding in reports would be my +100!

[qwerty]

Actually I dreamed of that: sitting in a team meeting at Sparx and finally I awoke when the PM said "Fine, let's settle this to be released at December 2099". Somehow that PM resembled the project manager at Berlin Airport.

q.

[Glassboy]

SVG would seem to be the logical choice for a scalable vector graphical icon set. It was invented for that purpose.
Being able to SVGs, and even better, SVG templates for elements, icons, and embedding in reports would be my +100!

If you search the forum you'll find one of the Sparxians telling me that wouldn't work.

[qwerty]

Haha. Nice suggestion. Searching for SVG just returns this very thread. If that search wouldn't be such a PITA people eventually would use it.

q.

[Eve]

As a replacement to shape scripts, svg is not practical. In theory they could contain javascript that would allow them to do the kind of things shape scripts can, but it wouldn't be pretty.

As icons, ui elements and alternate images they are overkill. With an appropriate subset, they would be ideal.

[timoc]

As a replacement to shape scripts, svg is not practical. In theory they could contain javascript that would allow them to do the kind of things shape scripts can, but it wouldn't be pretty.

As icons, ui elements and alternate images they are overkill. With an appropriate subset, they would be ideal.

Not to replace shapescript, as an alternative to shapescript. Even just as a passive document fragment type (alongside rtf, and csv) with "{{ mustache }}" substitution for embedding SVG's in reports, it would cover my current needs.

In my humble opinion, there is an overwhelming case for SVG support, regardless of the engineering required. It would seem to me, that the benefits of an XML DOM based non-bitmap format for your visual assets, available in well maintained off the shelf libraries would only be a benefit. Especially if your core technology-base includes XML,  XSLT, document generation, etc. More so if your product is about building and visualizing complex domain specific information and models, generating High DPI printable domain specific documentation, and even creating domain specific visual modeling languages.

As a one off engineering cost, putting together visuals such as model icons and shape templates is a task better handed off to a graphic artist, and not the (presumably more valuable) time of an EA user. Also everyone (including EA) does not have the overhead of EA and 'ShapeScript' unless they need scripting support.

[Ian Mitchell]

In this case, I have every sympathy with Sparx - this DPI scaling this is REALLY tricky. I've been looking at it for eaDocX and Model Expert for a while now, and I still can't make it work reliably. So lets cut the Sparx team a bit of slack on this one.
Even you, Q :-)

[timoc]

In this case, I have every sympathy with Sparx - this DPI scaling this is REALLY tricky. I've been looking at it for eaDocX and Model Expert for a while now, and I still can't make it work reliably. So lets cut the Sparx team a bit of slack on this one.

Sorry, I didn't mean to come across as giving anyone a hard time. 

I agree DPI scaling is very tricky, its a classic scaling problem when rendering a fixed bitmap based visual asset onto a different size/bit-density/colour-map etc. You are either (generally) adding pixels or removing them, while trying to keep high fidelity, without any context to reference. There is an argument that says GPU's were created specifically because manipulating and rendering bitmaps such a difficult problem.

I pointed out SVG because it is not a bitmap based technology, and so pushes DPI related scaling complexities into to the libraries, OS and the rendering hardware.