that's strange as on my system this patch made the difference between stuttering and being able to set that we might need better double-buffering as well. :-\
When you say handles, I suppose you mean Windows HANDLE data type? Do you to which kind of resource these handles refered?
In any case, I think adapting the tile size would be nicer than a hard limit, e.g. using 16 MB instead of 4 MB tiles above some specific number of tiles per page. I am not sure whether I will implement this for 0.4.14 depending on how difficult it is.
In any case, I'll merge this and make "TileItem::cancelRender" inline. I also think the signal-slot invocation using "QTimer::singleShot" within "TileItem::deleteAfterRender" could be replaced by a simple flag to further reduce overhead.
Hello,
that's strange as on my system this patch made the difference between stuttering and being able to set that we might need better double-buffering as well. :-\
When you say handles, I suppose you mean Windows HANDLE data type? Do you to which kind of resource these handles refered?
In any case, I think adapting the tile size would be nicer than a hard limit, e.g. using 16 MB instead of 4 MB tiles above some specific number of tiles per page. I am not sure whether I will implement this for 0.4.14 depending on how difficult it is.
In any case, I'll merge this and make "TileItem: :cancelRender" inline. I also think the signal-slot invocation using "QTimer: :singleShot" within "TileItem: :deleteAfterRen der" could be replaced by a simple flag to further reduce overhead.
Thanks for the review! Best regards, Adam.