I should check the Canvas code too, since I found:

canvas\src\com\icesoft\faces\canvas\Canvas.java
Method: render(UIComponent)

Canvas.encodeChildren(FacesContext)
DataPaginatorRenderer.renderFacet(FacesContext, DataPaginator, UIComponent, String)

trunk : revision 16837
branch 1.7: 16838

Changes made to the both GmapLatLngs and GMapMarker.
It doesn't apply on GMapRenderer as it takes only designated children and it maps the javascript visual elements with the JSF component, so even on render=false on any of its children, GMapRenderer delegates the encoding to it children, where it children decides to send remove command for appropriate visual element to the GMap library.

Fixed com.icesoft.faces.component.menubar.MenuItemRenderer, com.icesoft.faces.component.menubar.MenuItemRendererBase and com.icesoft.faces.component.panellayout.PanelLayoutRenderer as suggested by Mark.

changes made to the GMapMarker also reverted as the encodeBegin of it using the renderer flag to send remove command to the google map library.

Here's an example of a test case for panelLayout:

<ice:panelLayout layout="flow">
<ice:outputText value="This text should display"/>
<br/>
<ice:outputLink value="http://www.icefaces.org" title="There should be an image in here">
<ice:graphicImage alt="Home" url="http://www.icefaces.org/main/css/images/tools_home.gif"/>
</ice:outputLink>
</ice:panelLayout>

Before Yip's fix, the image would not show up, and afterwards, it now should.

TRUNK
Subversion 16849
icefaces\component\src\com\icesoft\faces\component\datapaginator\DataPaginatorRenderer.java

ICEfaces 1.7 branch
Subversion 16850
icefaces\component\src\com\icesoft\faces\component\datapaginator\DataPaginatorRenderer.java

Changes caused regression issue: ICE-3174.

False alarm.