This issue just arose last evening. I am migrating from one laptop to another, and both were operating Win 10 and had the screen resolution set to the recommended setting.

I run two projects - SETI @ home, and Einstein @ home. When I installed them, I noticed that the Einstein graphics are expanded to about 3 or 4 times normal size. Instead of seeing a "constellation globe" as I usually do, I see only a portion of the globe expanded to the screen. The SETI project graphics show up as normal.

I have never experienced anything like this before. Any ideas on why the Einstein graphics are over-sized while the SETI graphics are fine? This did not happen on my old laptop, nor does it happen on my desktop unit.

I am running BOINC 7.8.3, 64-bit.

ceetiger

I suggest you raise this on the Einstein message boards, if you haven't already.

Their forum moderator Mike Hewson has himself played around with the graphics display program: I suspect the difference may be due to the different programming languages chosen by the programmers at the two independent projects. Mike may be able to advise better.

Oooh, I'll give this a shot ! :-0

Short answer : the E@H screensaver is old code and refers to driver characteristics that may no longer be true. The driver for your second laptop may not conform to OpenGL standards for the interface version required by E@H. NVIDIA has promised to always provide faithful behaviour when presented with such older interface requests. Contrast that with Intel laptop drivers that almost always don't.

Long answer : Around 2011 the Khronos Group that manages OpenGL standards decided that conforming drivers ( v3.1+ ) no longer had to adhere to backwards compatibility. Having said that, if a driver does offer pre v3.x facilities ( required by the screensaver ) the expectation is that it would adhere. But I believe my research indicates that a driver may claim OpenGL functionality and yet not deliver. The especially tricky bit within the code is during initialisation when one attempts to gain a context for drawing. Think of a context as a ( usually double buffered ) rectangular plotting area, maybe the size of a whole screen, that one can animate upon provided that the operating system allows this area to be the client area of a window. The 'allows' is non trivial to code and E@H code uses a third party library ( TPL ) to obtain a context. Windows systems have a further coding burden in that M$ has not provided any headers for static linking with OpenGL calls for about 20 years now. The exception is a function to provide a pointer to the driver, and once that is obtained another function to dynamically obtain ( ie. at runtime ) the pointers ( addresses ) of all the remaining OpenGL interface. This is perverse. Internally the TPL will rely upon static capture of names in it's header at compile time, plus it populates a call table at runtime. A kludge which usually works. There are several TPL's but all are maintained by volunteers. In any case who can say what isn't happening properly in the above interaction ? Clearly an incorrectly sized context was acquired.

FWIW I have re-written the E@H screensaver library to accommodate v3.2 capable drivers. However the v3.2 OpenGL interface is dramatically more low level than v1.x and v2.x, such that detailed knowledge of the OpenGL rendering pipeline is required. One can no longer just simply ask for, say, a line of some color and thickness to be drawn b/w two context coordinates. You have to go through a whole rigamarole to setup and then fire the pipeline into activity. I wrote, in my opinion, a beautiful object oriented library that virtualises the pipeline. I was subsequently stunned to find that I had closely anticipated alot of the flavour of the v4.x interface, which had returned to a somewhat higher level representation of shader behaviour. I gave up in disgust at that point, especially as of 2011 Khronos had claimed 'forward compatibility' would be the go. A sneak look at v5.x plans shows another sea change on the way. What a committee camel. The E@H developers don't have the time to track & trap any of this, nor do I anymore ......

Cheers, Mike.

---

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal