Go Down

Topic: Arduino IDE window really small on High DPI Dispay? (Read 54165 times) previous topic - next topic


Mar 18, 2015, 05:00 am Last Edit: Mar 18, 2015, 05:00 am by Paul Stoffregen
Where to put the feedback? here?
Post it as a comment on github.  You'll need a free github account to post there.


Do you think the Dev's would like it if you/I/we/somebody will change the code in order to have the Splash-Screen beeing loaded like any other image, too (without having checked the possiblity of doing so, yet) ?

I know you have no HighDPI display, but I do. So I have a natural interest in having the ArduinoIDE running fine on HighDPI displays :D


I'm probably going to buy a laptop with such a display later this year.  Seems like a good idea to wait for Windows 10 though.

Probably best to ask Frederico Fissore directly, on the GitHub issue.  He and the other Arduino devs sometimes read these forums, but they always see stuff on GitHub.

At the moment, I'm working on the library dependency detection issue... so I'm mostly moved on from work on resolution scaling.  It's mostly up to Frederico & Cristian if they want to accept this contribution.  I really don't think there's much more I can do here.


You should rather wait for any Linux Desktop Platform to support HighDPI as compfortable as you would like it :D

That's why I stick with Windows at the moment. Many programs I use (Eclipse, Gimp, ArduinoIDE and so on) simply do not scale or at least only partially. That really is a pain in the ass (I guess that is because of the lack of a common, generic interface to access such information). However, that only is a mater of time.

I will try to create a patch so the splash screen is scaled, too. If I can manage it I'll ask the Devs. If not it does not matter. The current changes will allow a normal work on HighDPI displays, that's all that really matters.


I'm actually planning to buy that new 12 inch macbook air.  It'll give me access to the latest OS-X and the latest Windows (if I wait a bit...) and a high res display, all in 1 convenient machine that doesn't take up much space.  So far, I've managed to stay on top of most software issues without good access to the very latest stuff, but Apple's new OS is causing minor issues and Windows 10 is almost certain to bring a whole new crop of problems.

I have a very tiny workbench and office, which is becoming increasingly crowded as I try to keep working hardware on-hand for nearly all Arduino libraries!


Hm okay - a mac should simply do fine :)
Nice piece of hardware if 12" is enough ( I really thought about to buy one, too )


Played around with the splash screen.
It is set as a parameter to the java JRE but can be accessed within the java-code.
They already do this in Arduino\app\src\cc\arduino\view\SplashScreenHelper.java in order to draw the status text (Loading this...doing that...Starting ...) to the bottom of that splash screen.

I was able to scale the image (but it was clipped to the size of the old splash screen. I think its a matter of bounds I have not updated).

How ever - I noticed that it took a while until Java resized the Image. Felt like some few seconds (3 or 4) on my very fast PC. So I think this would not make any sense if the splash screen is resized seconds after the original one is displayed.

Maybe something comes into my mind later.


Had an idea:

use the Arduino Logo "laying eight" as a startup splash screen and replace it with a scaled splash-screen picture once "SplashScreenHelper" has access to it.
Should do fine because the status messages are displayed when SplashScreenHelper is loaded.

I wil try to do it myself when I find a quite hour but I'd like to share the idea.


Mar 25, 2015, 05:02 pm Last Edit: Mar 25, 2015, 05:03 pm by the-fallen
I tried to put my idea into code.
This is what I have done so far:

- once SplashScreenHelper is instanciated I get the background image URL
- loading a new instance of the splash image
- painted the new instance as a resized image to the graphics component of the splash screen

That really works so far but I need to use a trick:

- the dimensions of the splash screen can not be changed so it keeps the size of the original splash screen image.
- to be able to display a larger version I added a big transparent border around the splash image so the frame is bigger than it appears
- I display the resized instance starting a bit offscreen (depending on the scale factor) so you can display the resized instance still centered on screen.

Now the thing that does not work:
- because the original splash image has transparent areas I am not able to draw over them.
- if I make those transparent areas only 50% translucent, the new contant I will draw over it is also 50% translucent on those areas
- I found out that this is because the graphics object I get from the splash screen is an overlay to the original splash screen and this is using a SRC_ATOP rule. Under this rule, the alpha value of a pixel on the overlay remains whatever it was in the original image. This rule seems not to be changable because I have no access to the original graphic but only to the overlayed one

Maybe somebody else has more ideas?

Another solution may be not  to alter the splash screen but to display a decorationless frame once SpalshScreenHelper is instanciated and do all the magic there.

I would like to know what the developers of Arduino think before I continue so I will not waste time on ideas that are inacceptable.

Thanks in advance :)


Probably best to post this on Github, where Federico Fissore is more likely to see it.

Ultimately he's the Arduino dev in charge of that part of Arduino.  It's up to him how this stuff should be done, and what he's willing to accept and merge into Arduino.

The fact that nothing has happened on the code so far isn't a good sign though.  Maybe after the dust settles from "Arduino Day" might be good time to remind him and ask for input on the splash screen.


Okay, I just did so. Thanks again for your help.


I just watched this past week's "Ask and Engineer" from AdaFruit and Masimo was there. He did mention that the (or one of the) focus for the next release is on the actual editor. Hopefully the changes that you guys have been working on above will be considered.

Two quick questions (but might not be a quick answers...) are the changes above compatible with the latest 1.6.4 release? And, do they resolve the issue with the library and board managers having mircoscopic text on high DPI screens? (Currently to read them comfortably I have to use Microsoft's magnifier program.)


May 10, 2015, 08:12 pm Last Edit: May 10, 2015, 08:13 pm by Paul Stoffregen
Two quick questions (but might not be a quick answers...) are the changes above compatible with the latest 1.6.4 release?
No.  Much has changed since it was written.

That's how code contributions go.... easy to merge when they're first contributed, but harder and harder to integrate as other changes impact surrounding code.

And, do they resolve the issue with the library and board managers having mircoscopic text on high DPI screens? (Currently to read them comfortably I have to use Microsoft's magnifier program.)
Probably not.  That stuff was all developed privately and released as approx 120 commits with many thousands of new lines of code, only hours before 1.6.2 was published.

This high-dpi work was done based on the 1.6.1 code, and all that stuff was not available to me or any other contributors.




I adapted the patches to the latest 1.6.6 source code (17. 07. 2015 0600GMT) and they are working.
I put them here: http://pastebin.com/AWwdgjMV

I also posted that on GitHub but somebody needs to do the merge request.

Go Up