提高dc_client_draw_point的效率

发布于 2019-08-03 22:16:03 浏览：1349 订阅该版

* 本帖最后由 aozima 于 2019-8-10 09:51 编辑 *

如果您还在使用之前的rtgui0.41~rtgui1.0,可以看看这个帖子.这里不讨论新的柿饼UI,对于绘制图片/字体等之类的操作,最终调用的都是_draw_point()函数,它的效率至关重要.
这里分析client类型的dc,它是最慢的那一环,源代码如下:
```static void rtgui_dc_client_draw_point(struct rtgui_dc *self, int x, int y)
{
    rtgui_rect_t rect;
    rtgui_widget_t *owner;

if (self == RT_NULL) return;
        if (!rtgui_dc_get_visible(self)) return;

/* get owner */
    owner = RTGUI_CONTAINER_OF(self, struct rtgui_widget, dc_type);

x = x + owner->extent.x1;
    y = y + owner->extent.y1;

if (rtgui_region_contains_point(&(owner->clip), x, y, &rect) == RT_EOK)
    {
        /* draw this point */
        hw_driver->ops->set_pixel(&(owner->gc.foreground), x, y);
    }
}```

各版本的源代码区别不大,都与上述类似.该函数每次都需要调用rtgui_region_contains_point(),
以判断点(x,y)是否位于可绘制clip之内,它的消耗是不可控的,与clip的复杂度成正比,造成
绘图效率下降,改造这个地方,不要每次都调该函数;
方法是充分利用&rect参数;改造代码如下:
```struct rtgui_dc
{
    /* type of device context */
    rt_uint32_t type;
    rtgui_rect_t draw_rect; //增加一个辅助绘图的rect
    /* dc engine */
    const struct rtgui_dc_engine *engine;
};
```

在rtgui_dc_client_create()中初始化draw_rect
```dc->draw_rect.x1 = 0;dc->draw_rect.y1 = 0;
dc->draw_rect.x2 = 0;
dc->draw_rect.y2 = 0;
/////////////////////////////////////////////////////////////////////////////////
static void rtgui_dc_client_draw_point(struct rtgui_dc *self, int x, int y)
{
    rtgui_rect_t rect;
    rtgui_widget_t *owner;

if (self == RT_NULL) return;
        if (!rtgui_dc_get_visible(self)) return;

/* get owner */
    owner = RTGUI_CONTAINER_OF(self, struct rtgui_widget, dc_type);

x = x + owner->extent.x1;
    y = y + owner->extent.y1;

if(rtgui_rect_contains_point(&dc->draw_rect, x, y)) //先从辅助rect中查找
        goto do_drawing;
    else if(rtgui_region_contains_point(&(owner->clip), x, y, &dc->draw_rect)==RT_EOK) 
        goto do_drawing;
    else
        return;
do_drawing:
        /* draw this point */
        hw_driver->ops->set_pixel(&(owner->gc.foreground), x, y);
}```

总结,每次绘制点,先判断是否位于draw_rect内,第一次当然会失败,后面会再从region.rects中
判断,并取得找到的rect,它作为draw_rect使用,当下次再绘制点时,p(x+1,y)或p(x,y+1)非常高
的概率是在draw_rect之内的,这样就降低了调用rtgui_region_contains_point()的次数至
region_data.numRects*2+1次;

15 个回答

bernard 2019-08-09

这家伙很懒，什么也没写！

bernard 2019-08-03

这家伙很懒，什么也没写！

iamyhw 2019-08-06

这家伙很懒，什么也没写！

iamyhw 2019-08-06

这家伙很懒，什么也没写！

iamyhw 2019-08-08

这家伙很懒，什么也没写！

[i=s] 本帖最后由 iamyhw 于 2019-8-8 22:08 编辑 [/i]

测试:
环境:vS2012, 测试屏幕大小:640x480,颜色深度:16bits,测试场景如下图所示:
[attach]9987[/attach]
在一个容器控件中,放置一些干扰控件,使容器控件的clip变得复杂一点,
然后在容器控件的RTGUI_EVENT_PAINT事件中使用如下代码填充容器背景:
int draw_point_cnt_track; //记录进入rtgui_region_contains_point()函数的次数

```

draw_point_cnt_track = 0;
tick = rt_tick_get();
//fill by draw_point
for(y=rect.y1; y<rect.y2; y++) {
        for(x=rect.x1; x<rect.x2; x++) {
                rtgui_dc_draw_color_point(dc, x, y, color);
        }
}
rt_kprintf("cnt:%d, tick: %d\n", draw_point_cnt_track, rt_tick_get()-tick);

```

在rtgui_dc_draw_color_point()函数中记录次数:

```

if (INRECT(&(self->draw_rect), x, y))
        goto do_drawing;
    else if (rtgui_region_contains_point(&(owner->clip), x, y, &(self->draw_rect)) == RT_EOK) {
        draw_point_cnt_track++;
        goto do_drawing;
    } else
        return;

do_drawing:
        /* draw this point */
        hw_driver->ops->set_pixel(&color, x, y);

```

测试结果如下,包含rtgui_region_dump()的结果:
GUI simulator ....
finsh>>clip: num_rects:115
extents: (0,0) (640,480)
box[0]: (0,0) (640,10)
box[1]: (0,10) (10,30)
//......
box[113]: (630,450) (640,470)
box[114]: (0,470) (640,480)
cnt:1866, tick: 4
在每个box内平均调用rtgui_region_contains_point()的次数约16次多点,
而原先的代码,每绘制一个点,都要进入一次的,测试例程调用的次数为:
cnt:155400,tick: 8
调用次数即像素数,
可以看出,调用rtgui_region_contains_point()的时间开销约4tick,也就是说它
占用了整个绘制过程的一半时间,整个绘制过程是调用许多个函数过程的,
所以,此处优化会带来较大的效率提升.=========================================================
补充:上面的方法不严谨,又重新设计了跟踪次数的计算模型,实际上,执行到最
后的else return;时,也调用rtgui_region_contains_point()了,
当,需要绘制的点不在clip的rects列表中时,这时候绘制点是没意义的,但是
都要扫一遍,因为只有扫完一遍之后才知道无效,这个时候的效率表现最差!
这也是dc_client效率低下的原因.
理论上,绘制全显的比半遮挡的效率高(例如窗口及其控件被遮挡),从上往下和
从左到右比乱序的效率高.

iamyhw 2019-08-08

这家伙很懒，什么也没写！

bernard 2019-08-09

这家伙很懒，什么也没写！

iamyhw 2019-08-09

这家伙很懒，什么也没写！

iamyhw 2019-08-09

这家伙很懒，什么也没写！

[i=s] 本帖最后由 aozima 于 2019-8-10 09:51 编辑 [/i]

使用新思路重新设计了点在clip.rects中的命中逻辑,增加了无效快速检测,代码如下:struct dc中增加
struct rtgui_rect draw_rect; /* 记录命中的有效rect */
struct rtgui_rect invalid_rect; /* 记录无效的rect */

增加下面的函数,判断点是否属于容器下的某个子控件,如果是,则返回其extent,作为invalid_rect

```
static int _container_include_point(rtgui_container_t *container, int x, int y, rtgui_rect_t *rect)
{
        rtgui_list_t* node;

rtgui_list_foreach(node, &(container->children))
        {
                rtgui_widget_t* w;
                w = rtgui_list_entry(node, rtgui_widget_t, sibling);
                if(INBOX(&(w->extent), x, y)) {
                        *rect = w->extent;
                        return RT_TRUE;
                }
        }
        return RT_FALSE;
}
```

改造rtgui_dc_client_draw_point和rtgui_dc_client_draw_color_point函数

```
    if(INBOX(&(dc->draw_rect), x, y)) { track_hit++; /* 跟踪命中次数 */
        goto do_drawing;
    } else if(INBOX(&(dc->invalid_rect), x, y)) { track_cavity++; /* 跟踪空洞次数 */
        return;
    } else if(rtgui_region_contains_point(&(owner->clip), x, y, &self->draw_rect)) { track_seek++; /* 跟踪扫有效rects次数 */
        goto do_drawing;
    } else { track_fail++; /* 跟踪扫无效rects次数 */
        if(RTGUI_IS_CONTAINER(owner))
            _container_include_point(RTGUI_CONTAINER(owner), x, y, &(dc->invalid_rect));
        return;
    }
do_drawing:
    /* draw this point */
    hw_driver->ops->set_pixel(&(owner->gc.foreground), x, y);
```

测试结果,直接测试rtgui_image_blit函数的性能,
[attach]10038[/attach]
hit:153534, cavity:150290, seek:1866, fail:1510, tick:1
只判断有效命中的代码的测试结果:
hit:153534, cavity:0, seek:1866, fail:151800, tick:4
原先的代码(每次都扫描clip的rects列表)的测试结果:
hit:0, cavity:0, seek:155400, fail:151800, tick:9

使用最新思路设计的代码,时间复杂度几乎与剪切域的复杂度无关了,
其效率已逐渐逼近dc_hw,这个提升是非常显著的.
我再多测试其稳定性,比较新旧引擎代码的差异.