Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Goban grid lines are much blurrier in 20.1 #175

Closed
rooklift opened this issue Mar 10, 2017 · 15 comments · Fixed by #237
Closed

Goban grid lines are much blurrier in 20.1 #175

rooklift opened this issue Mar 10, 2017 · 15 comments · Fixed by #237
Labels
Milestone

Comments

@rooklift
Copy link
Contributor

rooklift commented Mar 10, 2017

http://i.imgur.com/JxHh6nW.png

On the left is 20.0, on the right is 20.1.

The lines on the left are much crisper and sharper.

Although this is the default theme, things are also like this on my own theme. Did something change in how lines are drawn?

@yishn
Copy link
Member

yishn commented Mar 10, 2017

No, the way how lines are drawn didn't change, but I did upgrade Electron to v1.6.1, which comes with an upgraded Chrome version, which might be responsible for this...

I'm noticing that the bottom bar in v0.20.1 is bigger than in v0.20.0, which might indicate that the zoom level of the web page has changed. Your Windows has a larger zoom level than Windows has as standard. It might be the case that Electron v1.6.1 is adjusting the zoom level depending on your system settings resulting in all non-vector images being blurry, but I'm really just guessing here...

@yishn yishn added the electron label Mar 10, 2017
@rooklift
Copy link
Contributor Author

That'll be it, I'm sure. I have everything at 125% size in the Display control panel.

@yishn
Copy link
Member

yishn commented Mar 10, 2017

Maybe it's a good idea to replace all grid line images with vector images. It won't fix the wood texture being blurry, though.

@rooklift
Copy link
Contributor Author

rooklift commented Mar 10, 2017

Uh, I wonder how much trouble it would be to add some sort of workaround as an option in the settings.json, where I could ask for 0.8 size to counteract it, and then the code would do something like:

let contents = win.webContents;
contents.setZoomFactor(0.8);         // Or whatever is set...

I'll try and submit a pull request if I can make it work.

@yishn
Copy link
Member

yishn commented Mar 10, 2017

That would be very quick and hacky; I can add a settings key for that. 😀

yishn added a commit that referenced this issue Mar 10, 2017
@yishn
Copy link
Member

yishn commented Mar 10, 2017

It's done, and the key's name is debug.zoom_factor. I'll keep this issue open for the vector images of the grid lines.

@rooklift
Copy link
Contributor Author

rooklift commented Mar 10, 2017

Thanks, good to have.

Edit: Yes, I can confirm this fixes it.

@rooklift
Copy link
Contributor Author

Although the bad news is that the saved window size now doesn't really work.

@yishn
Copy link
Member

yishn commented Mar 10, 2017

Can you elaborate on that?

@rooklift
Copy link
Contributor Author

When I set to 0.8, the window gets bigger every time I open the app.

yishn added a commit that referenced this issue Mar 10, 2017
@yishn
Copy link
Member

yishn commented Mar 10, 2017

I've hopefully added a fix for that, can you try it?

@rooklift
Copy link
Contributor Author

Yes I think that's working now.

@yishn yishn closed this as completed in 1223f45 Mar 10, 2017
@yishn yishn added this to the v0.21.0 milestone Mar 10, 2017
@rooklift
Copy link
Contributor Author

rooklift commented Mar 11, 2017

It's a minor thing, but (with a setting of 0.8) the menu in the bottom right (Pass, Resign, Edit, etc) is placed too far right and down.

The cause is view.js lines 1146-1147 though I'm not sure how to deal with it.

@yishn
Copy link
Member

yishn commented Mar 11, 2017

I guess everything that measures the DOM for menu placement is bound to have some errors. I don't think this can be fixed... Unless we open the menu at the current mouse position instead.

@rooklift
Copy link
Contributor Author

rooklift commented Mar 11, 2017

Making it

    Math.round($('#headermenu').offset().left * setting.get('debug.zoom_factor')),
    Math.round($('header').offset().top * setting.get('debug.zoom_factor'))

I think works. Although I don't know how many places in the code would need to be littered with this stuff. Perhaps best not to.

(I've been experimenting with Electron a little myself and find this interaction with Windows scaling (if the user, like me, has chosen something like 125% system-wide) to be annoying...)

Still, I think I can probably make some image files for my own use that have a tolerable result, then I can turn debug.zoom_factor back to 1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants