提供展示代碼：

成都創(chuàng)新互聯(lián)公司，為您提供成都網(wǎng)站建設(shè)公司、成都網(wǎng)站制作公司、網(wǎng)站營銷推廣、網(wǎng)站開發(fā)設(shè)計，對服務(wù)成都高空作業(yè)車租賃等多個行業(yè)擁有豐富的網(wǎng)站建設(shè)及推廣經(jīng)驗。成都創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司成立于2013年,提供專業(yè)網(wǎng)站制作報價服務(wù),我們深知市場的競爭激烈，認(rèn)真對待每位客戶，為客戶提供賞心悅目的作品。 與客戶共同發(fā)展進(jìn)步，是我們永遠(yuǎn)的責(zé)任！

      agg::rendering_buffer &rbuf = rbuf_window();
      agg::pixfmt_bgr24 pixf(rbuf);

      typedef agg::renderer_base<agg::pixfmt_bgr24> renderer_base_type;
      renderer_base_type renb(pixf);

      typedef agg::renderer_scanline_aa_solid<renderer_base_type> renderder_scanline_type;
      renderder_scanline_type rensl(renb);

      agg::rasterizer_scanline_aa<> ras;
      agg::scanline_u8 sl;
      ras.reset();

      double x[4];
      double y[4];
      double h =100.33;

      x[0] = 10;  y[0] = 10;
      x[1] = 100; y[1] = 10;
      x[2] = 100; y[2] = y[0]+h;
      x[3] = 10;  y[3] = y[0]+h;

      agg::path_storage ps;
      ps.move_to(x[0],y[0]);
      ps.line_to(x[1],y[1]);
      ps.line_to(x[2],y[2]);
      ps.line_to(x[3],y[3]);
      ps.close_polygon();
      ras.add_path(ps);
      agg::render_scanlines_aa_solid(ras,sl,renb,agg::rgba8(255, 0, 0));
      ps.remove_all();
      ras.reset();
      ps.move_to(x[0]+10,y[0]+h);
      ps.line_to(x[1]+10,y[1]+h);
      ps.line_to(x[2]+10,y[2]+h);
      ps.line_to(x[3]+10,y[3]+h);
      ps.close_polygon();
      ras.add_path(ps);

      agg::render_scanlines_aa_solid(ras,sl,renb,agg::rgba8(255, 0, 0));

非常明顯的看出兩個矩形相鄰的邊界上出現(xiàn)一條淺淺的白邊。

郵件質(zhì)疑：

As you can see there is a brighter line between the two rectangles. I

know where it is from - this is a result of alpha blending of two

partially covered scanlines. And this is a problem form me.

Do you have any idea how to get rid of this line? I mean how to make

it in the same color as the rectangles. My application draws metafiles

and sometimes there are such shapes in them and I get ugly banded

drawings... Do you have any ideas?

如下是作者的解釋：

 it's a well known problem that can't be eliminated easily. It exists in

all SVG engies and appears as thin "web" upon the p_w_picpath, when you draw adjacent

shapes:http://www.antigrain.com/svg/index.htmlSay, initially you have color (0,0,0). Then you draw a white pixel on it with

0.5 opacity (which is equivalent 0.5 of pixel coverage). You will have

(0.5,0.5,0.5) which is correct. Then you draw another pixel upon it, also with

opacity=0.5. According to the color blending rules you will have

(0.75,0.75,0.75), not (1,1,1). This is what happens when you draw your

rectrangles.

The problem can't be easily solved. In the SVG example I use conv_contour to

dilate all polygons. But this solution isn't perfect and kinda unfair.

But you can't render a multicolor scene in such a way. It's possible only in

Macromedia Flash, but it requires not only another rasterization algorithm, but

also changing the whole data model. Your data shall be represented not as a set

of polygons, but as a set of edges with attributes - color on the left and

color on the right.

> Say, initially you have color (0,0,0). Then you draw a white pixel on it with

> 0.5 opacity (which is equivalent 0.5 of pixel coverage). You will have

> (0.5,0.5,0.5) which is correct. Then you draw another pixel upon it, also with

> opacity=0.5. According to the color blending rules you will have

> (0.75,0.75,0.75), not (1,1,1). This is what happens when you draw your

> rectrangles.

This is the color from the original post:

> >         ren_aa.color(agg::rgba(0.4, 0.3, 0.2, 1.0));

The opacity of the color is 1.0, not 0.5. So what Maxim tried to say is I 

guess something like this: "Then you draw a white pixel on it with 0.5 

pixel coverage (which is equivalent to 0.5 opacity)."

Now, forgive me for my ignorance if this is trivial, I really haven't had 

to think about this particular problem, but here's an idea: suppose you 

are doing a flash-like multicolor fill where you know that no polygon 

overlaps another (triangulation, tesselation, whatever). Can the blending 

rule in AGG be changed so that the alpha channel is not interpreted as a 

genuine alpha, but as a coverage percentage instead? So that for example 

in this particular case 0.5+0.5 would be 1.0? This wouldn't work if you 

also want alpha, but the presumption here is that you really don't need it.

> Now, forgive me for my ignorance if this is trivial, I really haven't had 

> to think about this particular problem, but here's an idea: suppose you 

> are doing a flash-like multicolor fill where you know that no polygon 

> overlaps another (triangulation, tesselation, whatever). Can the blending 

> rule in AGG be changed so that the alpha channel is not interpreted as a 

> genuine alpha, but as a coverage percentage instead? So that for example 

> in this particular case 0.5+0.5 would be 1.0? This wouldn't work if you 

> also want alpha, but the presumption here is that you really don't need it.

Actually, that's an idea, I'm not sure it's doable, but it's seems to be. One

pixel can be overlapped by many polygons even if the polygons themselves do not

overlap. 

http://antigrain.com/stuff/multipoly_cover.gif - the central pixel is covered

by 6 triangles. It means that there are 6 different cover values and 6 colors.

And the resulting color must be calculated as the weigted average, where weight

is coverage. But we should keep a whole list of coverage values for each pixel!

Another solution is to use the alpha channel for coverage values. Suppose we

have not RGBA, but RGBC color space. Initially all cover values are 0. At a

time we always operate with 2 colors and two coverage values. We accumulate the

coverage values (with clipping at 1.0) and calculate the resulting color as the

weighted average of 2 colors/covers. It looks very familiar, and remainds me

the formulae for alpha blending in plain (non-premultiplied) color space.

> And the resulting color must be calculated as the weigted average, where weight

> is coverage. But we should keep a whole list of coverage values for each pixel!

Assume for example that you have calculated values

  nom = (w1*a1+w2*a2+w3*a3)/(w1+w2+w3)   (the weighted mean so far)

  den = w1+w2+w3                         (the sum of weights so far)

Then you can calculate new values

  nom = (nom*den + w4*a4)/(den+w4)

  den += w4

Expanding those formulas you will get the correct results. That is, you do 

not need to keep a record of all the colors in order to calculate an 

update to the weighted mean, the mean so far plus the weight (kept in 

alpha) is sufficient.

摘自：http://sourceforge.net/p/vector-agg/mailman/vector-agg-general/?viewmonth=200504

當(dāng)前標(biāo)題：AGG第四十四課渲染問題：繪制較寬輪廓和尖銳邊緣
轉(zhuǎn)載源于：http://sd-ha.com/article24/popece.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、營銷型網(wǎng)站建設(shè)、微信公眾號、域名注冊、網(wǎng)站排名、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)