Closed dfabulich closed 4 years ago
Nice!! but:
subtle bugs ... make the code less maintainable over time
I love my retina display, but I vote NO on that. Not that I get vote! -- but I really want the project to be maintainable and survive the inevitable need to upgrade and migrate.
I think that's an understandable attitude, but if you review the code, you'll see it's not all that bad. Still, I anticipate a bunch of bugs like this in the future: "whoops, I forgot * dpr
… or is it / dpr
in this case…?"
For me and my eyes, this makes Trizbort look so much better that it's worth wrestling with the bugs.
It is indeed a nice feature and it doesn't affect that many places. I'd make it a point to refactor to some sort of CoordCalc
class that does the work, and is called whenever a screen coordinate is needed, though.
I've merged this change in.
Fixes #80.
This looks way better on my 16" MacBook Pro. But! It was extremely difficult code to write and work with. Pretty much all of these
* dpr
and/ dpr
s were discovered through painful trial and error. It wouldn't surprise me at all if I've introduced some subtle bugs, and it seems especially likely that this PR will make the code less maintainable over time.If your screen doesn't support HiDPI mode, you can manually set
App.devicePixelRatio
to 2 to get a sense of what it would look like.canvas.width
and.height
based on the CSS width/height100%
. So instead of the normal documented technique, incanvas.ts
we're setting the scale to be* dpr
and configuring a CSSwidth: calc(dpr * 100%)
andtransform: scale(calc(1/dpr))
App.centerX
and.centerY
are now proportionally larger, so we have to/ dpr
infindMouseCoordinates
, and* dpr
in places where we're settingcenterX
.