I'm experiencing painting issues when combining TScaledLayout and custom styles created from the bitmap style designer in fmx.
To demonstrate, I loaded the default custom style created by chosing "New style for VCL / FMX" -> "save as .style" in the bitmap style designer. I dropped several standard controls on some colored rectangles: The red & green ones on a TScaledLayout, the blue one directly on the form. As I stretch the form, colored lines appear on the controls on the ScaledLayout; the background is partially visible:
If I size the form to exactly match the design-time dimensions, the lines disappear. That seems like a pretty significant issue, I certainly can't use those two together like that. Does anybody have an idea for a possible fix or workaround?
Looks like this is a known issue with scaling and bitmaps. See the Google+ discussion here - https://plus.google.com/+PaulThornton/posts/ACAHkJD3a84. I'll quote Marco Cantu's thoughts:
I've found an internally reported issue of a similar case, but haven't
found one that matches this scenario. Certainly worth adding to quality
portal. Having said this, I fear that bitmap-based operations and
scaling don't really fit together very well, and it might be difficult
to have an all encompassing solution.
Let me explain with an example. Take a button. This is painted by FMX
with 9 sections (borders, corners, central part) so that regardless of
the size the bitmap elements are stretched in one direction at most,
often just draw. Stretching a single bitmap for the button to the
target size would break anti-aliasing and create a blurred image when
using colors.
This is example what happens with a ScaledLayout, given it takes the
complete final image and transforms it. ScaledLayout was originally
introduced with vector styles, and worked very well in that scenario.
With todays's bitmap styles things get a bit more complex.
Regardless of this explanation of there the issue lies, I'd recommend
reporting it on QC, and I'll make sure it doesn't get closed as design
(it could naturally happen, this is how the system works) but that we
do some investigation to address the issue -- turning this into a
feature request.
Related
I am trying to build a gantt control with Konva (does it make sense to use Konva for this)? I have tried to sketch the control below:
I was thinking of breaking down the Konvas stage as follows:
One stage with 4 layers: activity names, timeline, activity views, and scrollbar view.
The scrollbar layer would contain a "custom control" mimicking a standard scrollbar control.
At this stage I have a couple if questions:
What would be the best approach for synchronizing the different layers from an event handling perspective? For example if the user click's on the scrollbar's down arrow shape, I would need to "scroll" all layers one unit down.
How does the Konva coordinate system work? Is the drawing of shapes done relative to the containing layer?
What's the difference between a layer and a group? Does it make more sense to use a group instead of layers?
I realize my questions are very broad in nature, but at this point I need to get the design right.
I am responding here rather than as a comment because I have more to say than a comment allows.
I have made Gantts with both HTML elements, and another canvas lib, and Konva. I used Divs with jquery first and it was viable but I felt it got quite complicated and it ran out of steam in the area of zooming the view. You can't hide from the complexity of course. Switching to HTML5 canvas I realised that a lib like Konva would accelerate production. And zooming in canvas is simple.
As per #lavrton's comment, the text is primitive on HTML5 canvas when compared to GDI, or other, more mature tech. My answer for the labels on tasks was to use off-screen text drawing then converting to images which works very well. For popup editing, I revert to HTML divs etc. I did not use animations in the Gantt but I have elsewhere and canvas should be fine - there are plenty of bouncy-ball / particle tests around to confirm that.
As a coding design suggestion, the data model and functionality of the Gantt is consistent whatever tech you use to draw it with. I recommend you consider proceeding with a layered approach where your interaction with drawing functions is wrapped as class methods in a drawing class so that you can switch out the drawing tech itself should you feel the need. You could insulate yourself from the choice of tech and/or library that way.
Turning to aspects of your question:
layers are a useful concept. Physically each layer is an HTML5 canvas element. So multiple layers in one diagram are really multiple canvases over the same stage. The benefit here is in redrawing specific layers instead of the entire canvas where there are performance savings. But mostly you can ignore the physical and just get on and use the concept which works well.
groups: a group is a collection of shapes on a layer. If you have to draw things made of many shapes, grouping them is very useful because you can move the group as a whole, hide it, delete it, etc. You might, for example, consider making each taskbar, composed of at least a rectangle and text, as being a group. One consideration for groups is that the location and size of the group is that of the bounding rectangle that encloses the shapes within it. This can cause some confusion until you work out an approach. You will find yourself using layers and groups, but mostly groups for drawing controls.
Zooming / scaling: this is easy with a canvas. Less easy is the math for how to change the offset to keep the same view as you zoom, but again it is achievable.
Synchronised scrolling layers is not going to take any time to develop - just set the layer y-position for each layer.
Drawing the grid of rows for activity and columns for days/weeks/months/etc should not be underestimated as a task, but as you develop it you will learn the fundamentals of working with Konva.
Final point - the docs and examples for Konva could be a bit better, but the community support here and at https://konvajs.github.io/docs/ is good, and the Konva source code is also at that site so you can delve right in to understand what is happening, though you do not need to do that at all if it is not your thing.
A little background: I'm working on an iOS app that has a variety of status icons for various states. These icons are used in a variety of places and sizes including as UITableViewCell imageViews, as custom MKMapAnnotations and a few other spots. I actually have a couple sets which include a more static status icon as well as ones that have dynamic text injected into the design.
So at first I went the conventional route of using static raster assets, but because the sizes were dynamic this wasn't always the best solution and I wasn't thrilled with the quality of the scaling using CGAffineTransforms. So instead I changed gears a bit and tried something else:
Created a custom UIView subclass for each high level class of icon. It takes as input the model object that derives the status from (I suppose I could have also just used an enum and loaded this into some kind of model constructor but this is how I did it) so it can decide what it needs to draw, then does the necessary drawing in drawRect. Since all of the drawing is based on the view bounds it scales to any reasonable dimensions.
Created a Category which has class method constructors that take the model inputs as well as the size you want to use and constructs the custom views.
Since I also wanted the option to have rasterized versions of these icons to plug into certain places (such as a UITableViewCell imageView) I also created constructors that build the view and return a UIImage using the fast iOS7 snapshotting functions.
So what does this give me? Well here's the pros/cons that I can see.
Pros
Completely scalable graphics that can easily be used in a variety of different scenarios and contexts.
Easy compatibility with adding dynamic info to the graphics such as text. Because I have the exact shape data on everything I'm drawing I don't need to guesstimate on the bounds for a text box since I know how everything is laid out.
Compatibility with situations where I might want a rasterized asset but I still get all the advantages of the dynamic view since I'm not rasterizing it till I need it.
Reduces the size of the application since I don't need to include raster assets.
Cons
The workflow for creating the draw code in the first place isn't ideal. For simple stuff I can do it straight in code but for more complex things I'll need to create the vector asset in Illustrator or Sketch then bring it into PaintCode and clean up the generated draw code into something more streamlined. This is not the most ideal process.
So the question is: does anyone have any better suggestions for how to deal with this sort of situation? I haven't found an enormous amount of material on techniques for this sort of thing and I'm wondering if I'm missing a better way of handling this or if there are any hidden gotchas here...performance doesn't seem to be an issue from my testing with my approach but I haven't tested it on the iPad3 or iPhone 4 yet so there could still be some unknowns.
You could try SVGKit, which draws SVG files, and can export to a UIImage, if desired.
Recently I've discovered that TCanvas.StretchDraw will not work as expected for object which is a TIcon instance (quick look at TIcon.Draw and DrawIconEx method tells why). Delphi help acknowledges that fact. I know the workaround but I do not know the reason behind such design decision in VCL. Does anyone know why they decided to left TIcon untouched in this matter?
Icons are not regular bitmaps. This is mostly due to historical design and technical reasons.
It did make sense at time when icons were small 32x32 pixels large and 16 colors (good old days!) that icons were never to be stretched on screen.
But there is also a "common sense" technical reason. Such small bitmaps are usually very hard to be re-sized by an algorithm (and default GDI strech algoritm is very fast but produces also very bad result in respect to other interpolation modes, e.g. available with GDI+), so it was decided to embed a set of icons within the executable, as resources: one icon per size. The strech process benefits of being done at design time, at pixel level, by an icon designer. And - back those days - it was also much less resource consuming to use dedicated icons, with a reduced color palette.
Since you are supposed to have a set of icons with a pre-defined size for each, you do not need to use StrechDraw, but just select the right icon to display.
So if you want to display an icon with a given size, ensure you pickup the right size, or get the biggest icon and upsize it, using a temporary bitmap - or DrawIconEx(). Or, even better, do not use icons, but a bitmap, or a vectorial drawing if you expect huge picture size.
I am preparing to start on a C++ DirectX 10 application that will consist of multiple "panels" to display different types of information. I have had some success experimenting with multiple viewports on one RenderTargetView. However, I cannot find a definitive answer regarding how to clear a single viewport at a time. These panels (viewports) in my application will overlap in some areas, so I would like to be able to draw them from "bottom to top", clearing each viewport as I go so the drawing from lower panels doesn't show through on the higher ones. In DirectX 9, it seems that there was a Clear() method of the device object that would clear only the currently set viewport. DirectX 10 uses ClearRenderTargetView(), which clears the entire drawing area, and I cannot find any other option that is equivalent to the way DirectX 9 did it.
Is there a way in DirectX 10 to clear only a viewport/rectangle within the drawing area? One person speculated that the only way may be to draw a quad in that space. It seems that another possibility would be to have a seprate RenderTargetView for each panel, but I would like to avoid that as it requires other redundant resources, such as a separate depth/stencil buffers (unless that is a misunderstanding on my part).
Any help will be greatly appreciated! Thanks!
I would recommend using one render target per "viewport", and compositing them together using quads for the final view. I know of no way to scissor a clear in DX 10.
Also, according to the article here, "An array of render-target views may be passed into ID3D10Device::OMSetRenderTargets, however all of those render-target views will correspond to a single depth stencil view."
Hope this helps.
Could you not just create a shader together with the appropriate blendstate settings and a square mesh (or other shape of mesh) and use it to clear the area where you want to clear? I haven't tried this but I think it can be done.
In CSS Sprites you will often find padding between each image. I believe the idea is so that if the page is resized then one image won't bleed into another.
I think this depends on the different types of browser zoom (best explained by Jeff).
However, I haven't been able to see this behaviour in my tests. Is this only a problem with older browsers? (I havent been able to test with IE6 at the current time so I'm counting that as 'old').
Should I still worry about leaving space? Its kind of a pain.
For instance :
A CSS Sprite I found for AOL has
padding between each image : VIEW
but The Daily Show decided not to
bother : VIEW
It shouldn't need to be padded, but when zoomed, especially in IE8 (betas more than the RC), there is image bleeding if there is no padding.
Best example is to go to Google.com -> Search, and zoom... you'll start to see "underlines" at the bottom right of the image as the zooming rounds up/down.
In theory, a 1px padding on all sides of a sprite should be fine.
Here's the sprite from Google (images)...
But when zoomed, the +,-,x icons bleed into the main Google logo.
Basically the answer is yes. Two years to the day after I asked this question will see the release of IE9. IE9 has this problem just as much - if not more than any other browser...
It's pretty infuriating because it's such a simple thing to fix.
With iPads increasing in marketshare - its's pretty essential to at least have a half decent experience with zooming un-uniform amounts.
I am going to have to put a single pixel border around every image to match the background color of the adjacent element (potentially different on each side). Fortunately I auto-generate all my csssprites based on an .xml file - so I can do this programatically without too much hastle. It's still a huge pain though...
Simon - My experience is that this is certainly still a problem.
In response to your second question, why not use transparent padding? (Perhaps you are still supporting ie6 and this is non-trivial, in which case, I'm really sorry).
Speaking of the older browsers (those using text zoom), you don't always need padding.
The main difference between your two examples is that the Daily Show sprite already includes the menu item's text in the image itself.
When using text zoom, the AOL menu items could stretch out vertically due to the larger font size, and the menu text might even wrap to two lines. To accommodate for such eventualities, those icons need a little padding to ensure they don't bleed. Typically, you'd just try to make sure it doesn't bleed on any of IE6's five text sizes.
Since The Daily Show's menu doesn't contain any (visible) HTML text its size won't be affected by text zoom (though you might need a line-height: 0; or so to be sure), so it doesn't need any padding.
As scunliffe already showed, browsers using page zoom may need sprites to have a little padding due to rounding errors.