Project

Profile

Help

HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. *Read more...*

Task #696027

open

Zoom: get from beta to production quality

Added by Jacob Nevins about 5 years ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
gui-gtk-3
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

There are still a few glitches in the Gtk3 clients' zoom functionality. This is an umbrella for ones that aren't fatal.

Currently targeting 2.6.0, but probably won't block it if not done in time.


Related issues

Blocked by Freeciv - Bug #638737: Zoomed out, black background too smallClosedMarko Lindqvist

Actions
Blocked by Freeciv - Bug #685279: Unit movement trails at non-default zoom levelNew

Actions
Blocked by Freeciv - Bug #696026: Zoom: line artifact in fogged tiles at top of mapview New

Actions
Blocked by Freeciv - Bug #697657: Zoom: explosions not drawn properlyNew

Actions
Actions #1

Updated by Jacob Nevins about 5 years ago

  • Blocked by Bug #638737: Zoomed out, black background too small added
Actions #2

Updated by Jacob Nevins about 5 years ago

  • Blocked by Bug #685279: Unit movement trails at non-default zoom level added
Actions #3

Updated by Jacob Nevins about 5 years ago

  • Blocked by Bug #696026: Zoom: line artifact in fogged tiles at top of mapview added
Actions #4

Updated by Jacob Nevins about 5 years ago

  • Blocked by Bug #697657: Zoom: explosions not drawn properly added
Actions #5

Updated by Jacob Nevins over 4 years ago

  • Sprint/Milestone changed from 2.6.0 to 2.6.1

I haven't investigated the specific glitches in related tickets, but I don't recall Gtk3 zoom being obviously dodgy when I've briefly tried it in recent times. I think it is probably usable.

Actions #6

Updated by Anonymous over 4 years ago

There is easy way to make such zoom perfect. It would be 3X faster without glitches and easy ( still using a lot of cpu but about 200% less)
1) - remove all that crap
2) - Just scale mapview
3) - scale mouse clicks to fit mapview
4) - draw lines/text after mapview is scaled.

With current zoom every tile is drawn average with 1-5 sprites and each that sprite is scaled.
So probably for 1 tile on average 3 sprites with size of that tile are scaled.
In new zoom it would be 1 scale operation instead 500 like now ( and without scaling 3 sprites to draw 1 tile)

Actions #7

Updated by Jacob Nevins almost 3 years ago

  • Sprint/Milestone changed from 2.6.1 to 2.6.2
Actions #8

Updated by Jacob Nevins almost 3 years ago

  • Sprint/Milestone changed from 2.6.2 to 2.6.3
Actions #9

Updated by Marko Lindqvist almost 2 years ago

  • Sprint/Milestone changed from 2.6.3 to 2.6.4
Actions #10

Updated by Marko Lindqvist over 1 year ago

  • Sprint/Milestone changed from 2.6.4 to 2.6.5
Actions #11

Updated by Marko Lindqvist over 1 year ago

  • Sprint/Milestone changed from 2.6.5 to 2.6.6
Actions #12

Updated by Marko Lindqvist 12 months ago

  • Sprint/Milestone changed from 2.6.6 to 3.0.1
Actions #13

Updated by Marko Lindqvist 8 months ago

  • Sprint/Milestone changed from 3.0.1 to 3.0.2
Actions #14

Updated by Marko Lindqvist 8 months ago

Anonymous wrote:

With current zoom every tile is drawn average with 1-5 sprites and each that sprite is scaled.

Yep, but only the tiles that have changed are redrawn, not entire canvas like with your suggestion.

That said, it seems likely that gtk4 will force us to redraw entire canvas anyway, so with gtk4-client we probably implement exactly what you said.

Actions #15

Updated by Marko Lindqvist 6 months ago

  • Sprint/Milestone changed from 3.0.2 to 3.0.3
Actions #16

Updated by Marko Lindqvist 4 months ago

  • Sprint/Milestone changed from 3.0.3 to 3.0.4
Actions #17

Updated by Marko Lindqvist about 2 months ago

  • Sprint/Milestone changed from 3.0.4 to 3.0.5

Also available in: Atom PDF