Hi for some reason pie isnt working on my rounded corners, can anybody please help. Below is my CSS, in ie8 it doesnt show the background color either just the text within the button.
http://jsfiddle.net/doddsy1005/VcrGL/1/
may be due to a filter like this.filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#e4265b', endColorstr='#e10e49',GradientType=0 );
As per your remark in the question: yes, it may very well be due to the filter.
There is a well-known bug with gradients drawn using filter that messes up rounded corners. This bug is best known in IE9, because IE9 does support border-radius, but still needs filter gradients, so they often clash. I can easily see that it might break CSS3Pie's rounded corners as well though.
I guess the real question is why are you using filter at all for gradients? If you're using CSS3Pie for rounded corners, you can also use it for CSS gradients; it supports both features. The whole point of CSS3Pie is that you don't have to do things like use filter for gradients.
So the answer is simply to stop using filter for your gradients. Use CSS3Pie as you already do for border-radius, and the problem will go away.
Hope that helps.
Related
After sorting out the issues in this question, I was finally getting image data from my render target. BUT, that image data does not seem to use anti-aliasing. (It also doesn't seem to have any alpha values where 0 < a < 255, but that may be a different issue).
I saw in this thread that anti-aliasing isn't available for render targets, but that was in 2011. Is that still the case? Do I need to employ post-process anti-aliasing if I want it for my render target?
This issue is present in both r76 (what I'm using from my previous question) and even the latest, r86.
Here's an example image, if it helps. The gray background is the image rendered to the main canvas, while the transparent background comes from the render target. You can really see the aliasing on the edges between the faces.
this answer is some late (3 years later) but, in this discussion is the solution: https://discourse.threejs.org/t/why-is-a-custom-fbo-not-antialiased/1329.
With the next release of three.js (R101), it’s possible to use a new type of render-target to solve this problem. WebGLMultisampleRenderTarget enables the support of multisampled renderbuffers. You can now perform “render-to-texture” and have an antialiasing render result. A post-process AA like FXAA is not necessary anymore.
Important: It’s required to use a WebGL 2 rendering context since multisampled renderbuffers is a WebGL 2 feature. -
I'm getting strange problem with pie.htc and IE8. I have many elements on page that has rounded corners but pie works only for one element. My CSS is correct - I mean selectors are correctly assigned to pie behavior.
What elese could be wrong?
I have some experience using css3 pie and they have not been great. Here are the fixes i have used:
The elements that you are applying the behavior library too need to be position: relative for a start, so check that first. It may fix it.
If you want it to work in IE6 and 7 you need to add zoom: 1. I know you said you were using IE8 but my customers have said that in the past and it has been in compatibility mode, so always best to add that setting.
CSS 3 Pie does not support browser zooming either on background images so check that you are viewing the website in the 100% view and no other.
Hope that has helped. If you could post a jsfiddle then I could try and help further. If not check the css3pie known issues http://css3pie.com/documentation/known-issues/
Found a solution. Problem was that for these elements was used background with filter. Also css3pie sets background for these elements. After removing this filter everything works fine.
I am using flot to display a bar graph. Due to the long label of x-axis, I use a js plug-in which named jquery.flot.tickrotor.js.
The label looks fine on most computers. But on some computers, the letters in the label are kind of messed up and the font looks strange.
I really want to post the pic to show the display but I don't have enough reputation to do so.
Does anyone know what may cause this problem?
The labels are probably rotated using CSS transforms. Some browsers - mainly IE 7 & 8 - do a poor job of rendering the rotated labels.
If the plugin supports rendering text to canvas directly, enabling that should fix the problem. Otherwise there's nothing you can do about it. Since those browsers are disappearing from the market due to their age, the problem will eventually just disappear.
I have been working on getting this seat mapping chart for a while and have created a few iterations, and the problem I keep finding is when I get to IE8 the panning for this is way to slow and delayed.
What I have at this point to cut down on load time is created a png to replace my "strokes" since I assume ie8 wanted to re-render each time I dragged the map.
I also added controls hoping to force IE8 users this option, but still there is a delay in the pan, and if I can have users with IE8 (and ie7 if possible) still drag/pan without the controls and the respond time a little faster that would be great.
Here is my current JSFiddle
I am still a little green with JS so if you have any suggestions it would be much appreciated. (PS Chrome frame is awesome but is not a option for me)
Update
I have removed the original dragging function and replaced the code using jqueryui's draggable function. Martin had suggested to just drag the div, and not the Raphael elements. Doing so lets this thing fly in ie6-8 which is great, but then came my concern about scaling. What I was seeing before on zoom my paper element WxH would stay the same ratio, cutting off my drawing when it zoomed in. After digging through the Raphael documentation I came across paper.setSize. setSize was exactly what I needed to allow this project to move and groove in ie6-8 and pretty much conquer all browsers in its path.
So in short, using jqueryui's draggable and paper.setSize has cured my cross browser zoom n' pan blues.
From what can be seen in the Fiddle, you are triggering a new rendering of the image by calling .translate() inside of a mousemove event handler:
mapContainer.translate(currentMapPosX, currentMapPosY);
rsrGroupies.translate(currentMapPosX, currentMapPosY);
This approach is toxic for performance in all browsers, let alone IE8. When dealing with VML in IE8 you should consider that each and every DOM change inside the image will result in the image being rendered again. Doing that while panning will always be painfully slow.
I see that you are already using jQuery in your Fiddle. If you want to increase performance of your panning, you should consider doing the following:
Render the image in Raphaël exactly once for the current zoom level. Do not attempt to change transformations in your VML/SVG image at any point in time while panning.
With the mousemove implementation of panning you already have, move or scroll the HTML container that holds your VML/SVG image instead. Imagine a <div> with overflow: hidden and simply move the image inside relatively, or scroll to the appropriate position.
This will require some adjustment of your coordinate calculations, but it will improve your performance in all browsers.
I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.